单库单表性能瓶颈分析

什么是单库单表瓶颈

当业务发展到一定规模，一台 MySQL 实例和一个数据表无法承载全部流量时，就会出现性能瓶颈。理解这些瓶颈是决定是否需要分库分表的前提。

瓶颈的表现形式

1. 连接数瓶颈

MySQL 默认最大连接数通常为 151（或 1000+ 取决于配置）。当应用实例增多、连接池扩张时，很容易触及上限：

SHOW VARIABLES LIKE 'max_connections';
-- 默认值: 151

SHOW STATUS LIKE 'Threads_connected';
-- 运行中连接数

连接数被打满后，新的请求会被拒绝，表现为”Too many connections”错误。

2. CPU 瓶颈

单个 MySQL 实例受到服务器 CPU 核数限制。当查询量巨大或存在复杂查询时，CPU 成为热点：

• 大量并发排序（filesort）消耗 CPU
• 频繁的聚合计算（GROUP BY、COUNT）
• 索引扫描量大导致的 CPU 飚高
• 并发锁争用带来的上下文切换开销

3. IO 瓶颈

磁盘 IO 是数据库最常见的热点：

• 磁盘读 IO：查询未命中索引或索引选择不当，导致大量全表扫描
• 磁盘写 IO：binlog、redo log、数据文件的写入争抢 IOPS
• WAL 机制：innodb_log_file_size 配置不当导致频繁 checkpoint

使用 iostat 或 MySQL 的 SHOW ENGINE INNODB STATUS 可以观察 IO 状况。

4. 锁冲突瓶颈

单表的所有 DML 操作共享一把行锁或间隙锁。当并发量升高时，锁冲突显著增加：

• 热点行更新导致行锁等待
• 大事务的间隙锁导致大量插入阻塞
• DDL 操作（ALTER TABLE）导致表锁
• MVCC 版本链过长导致的回滚段争用

5. 磁盘容量瓶颈

单表数据量增长到数百 GB 甚至 TB 级别时：

• 备份时间极长（mysqldump 或 XtraBackup 耗时以小时计）
• 索引重建（OPTIMIZE TABLE）需要大量临时空间
• 数据文件超过文件系统单个文件大小限制

6. 缓冲池瓶颈

InnoDB 的缓冲池（buffer pool）大小受物理内存限制。当数据量远超 buffer pool 大小时：

-- 查看 buffer pool 命中率
SHOW STATUS LIKE 'Innodb_buffer_pool_read_%';

如果 Innodb_buffer_pool_read_requests 远大于 Innodb_buffer_pool_read_hits，说明数据需要大量从磁盘读取，性能会急剧下降。

量化评估指标

瓶颈诊断方法

-- 查看当前正在执行的查询
SHOW FULL PROCESSLIST;

-- 查看 InnoDB 状态
SHOW ENGINE INNODB STATUS\G

-- 分析慢查询
SELECT * FROM performance_schema.events_statements_summary_by_digest
ORDER BY SUM_TIMER_WAIT DESC LIMIT 10;

何时需要突破单库单表

当以下情况同时出现时，需要考虑分库分表：

1. 单表数据量超过 500 万-1000 万行（这个阈值需要根据实际情况判断）
2. 数据库持续出现 CPU/IO 瓶颈，且无法通过垂直扩容解决
3. 日常 SQL 操作（特别是写入）出现明显性能退化
4. buffer pool 命中率持续低于 95%
5. 备份和维护窗口无法接受

在达到这些阈值之前，应该优先考虑：SQL 优化、索引优化、缓存层引入、垂直扩容（升配机器）、读写分离等更轻量的手段。

面试要点

• 单库单表瓶颈本质上是资源（CPU/IO/内存/连接/锁）的争用
• 理解瓶颈是选择合适扩展方案的前提，不要盲目分库分表
• 先优化 SQL 和索引，再考虑架构层面的扩展
• 知道如何通过系统状态变量诊断具体瓶颈点
• 每个瓶颈在不同的业务场景下有不同的解决方案