MySQL索引碎片：大量写入如何拖垮查询性能及完整整理方案-代码聚汇网

MySQL索引碎片：大量写入如何拖垮查询性能及完整整理方案

小鹅通·2026-09-04·阅读 23 GEO检测（免费）

MySQL索引碎片B+Tree

|难度：普通|阅读约 39 分钟

先说一个我上个月处理的真实案例：一套业务系统在持续写入约三个月后，某天晚高峰出现大量SELECT慢查询，单条查询从20毫秒涨到接近1秒。检查CPU、内存、磁盘IO都在合理范围内，慢SQL日志里也没有冒出什么新写法，最后定位到问题出在索引碎片上——大量随机写入导致索引页不断分裂，索引逻辑上还在，但物理组织已经千疮百孔。这篇文章就围绕“大量写入让索引性能下降”这件事，把成因、判断方法、整理方案和长期维护策略完整讲一遍。

1. 大量写入场景下，为什么最先撑不住的是索引

很多人对索引性能下降的第一反应是“是不是没走索引”“是不是SQL写错了”，但在大量写入的场景里，SQL没有任何变化，统计信息也没有严重过期，慢查询却突然变多，这时候你就要考虑索引本身的物理结构已经被写入操作破坏了。

1.1 索引碎片的两副面孔：页面空洞与逻辑顺序错乱

InnoDB的索引使用B+Tree结构，叶子节点按主键或索引键的逻辑顺序排列。大量写入如果是有序的（比如自增主键），新数据会追加到当前页尾部，页面只需要在满时申请新页，结构相对规整。但如果写入是相对随机的，比如UUID主键、业务单号主键，或者频繁UPDATE导致二级索引键值变化，B+Tree就频繁发生页分裂。

页分裂的过程可以这样理解：一个索引页已经写满，此时又要插入一个新键值，InnoDB只能把一半记录挪到新页。问题在于，分裂出来的新页在物理存储上往往和原页并不相邻，但逻辑上它们必须在B+Tree里前后衔接，于是索引的叶子节点链表就变成了一段物理上分散、逻辑上连续的结构。每次查询在扫描索引范围时，InnoDB需要跳转不同的物理位置去读页，磁盘预读的连续性也被打断。

外表上你只看到“全表才500万行，索引也建了，为什么越来越慢”，实际上索引树的层数可能已经因为大量页分裂而变深，或者叶子页的平均填充率已经掉到50%-70%左右。B+Tree的本意是通过高扇出来减少树高、通过连续页来高效扫描，碎片恰恰破坏了这两个优势。

1.2 哪些现象像碎片问题，哪些其实和碎片无关

我见过不少同行一遇到索引性能下降就急着做碎片整理，结果方向完全错了。先把常见的“像但未必是”的情况理清楚：

表现	可能与碎片有关	更可能是其它原因
范围查询、排序查询变慢，单点查询正常	是	统计信息问题需先排除
新增数据量没涨多少，但索引文件体积明显膨胀	是，典型信号	也可能有大量未提交事务撑起undo
CPU使用率飙升、锁等待增加	未必	可能SQL没走索引、锁竞争
buffer pool命中率很高，但物理读仍居高不下	是，页被分散	也可能冷热数据分离失效
慢SQL集中在某几个UPDATE/DELETE高频表	是	也可能行锁竞争

一句话：碎片导致的性能下降，通常表现为逻辑读不高但物理IO次数偏多，或者索引文件大小与数据量严重不匹配。如果你在processlist里看到大量SELECT查询的Rows_examined并不高，但耗时却很长，就要开始怀疑页的物理布局出了问题。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 一次UPDATE引发的蝴蝶效应：索引页分裂的完整链路

要理解碎片，不能停留在概念层面，最好把InnoDB在页分裂时的操作链路拆开看。我以一张订单流水表为例，它有主键order_id varchar（业务单号），还有二级索引status。

2.1 页分裂的三步操作与产生的空洞

当一条新订单写入时，主键索引需要把order_id插入到对应叶页。因为业务单号不是严格递增的，插入位置常常落在一个已经写满的页中间：

第一步，InnoDB定位要插入的叶页。如果页还有空闲空间，直接插入并移动部分记录位置；如果页已满，就申请一个新页，把原页大约一半的记录移到新页。
第二步，调整上层索引节点，把新页的键范围和指针挂到B+Tree父节点。这一步如果父节点也满了，会继续向上分裂，极端情况下整个树的高度增加一层。
第三步，原来页和分裂出的页在文件系统的物理位置有相当概率是不连续的。即便是同一个段内申请的空间，由于并发写入会交替申请页，物理顺序也很难保持连续。

这个过程的副产品就是页空洞和逻辑碎片。旧的页因为挪走了一半数据，填充率降低，而所有无索引的堆表（InnoDB聚簇索引本身就是表数据）也会面临同样的空间散乱问题。大量UPDATE如果修改了二级索引的键值，相当于先DELETE旧键值再INSERT新键值，两轮页操作会让碎片以更快的速度累积。

2.2 定位一个写入热点时，碎片率随时间的变化

用实际观察数据来说明问题。我维护过的一张核心业务表，初始约180万行，索引占用约600MB，碎片率可以忽略。后来因为业务调整，该表开始由多个分库同时写入，主键从自增改为UUID，同时state字段频繁从0更新到1、2。

运行大约一周后，观察到的指标变化：

主键索引占用空间从600MB增长到1.4GB，但行数只增长到210万行。
information_schema里data_free显示超过300MB，索引文件膨胀和可回收碎片空间同步上升。
同一SQL从执行计划的key_len、rows上看没有变化，但实际执行时间从30ms涨到180ms。
buffer pool命中率保持在99%以上，但InnoDB_pages_read并没有明显下降，说明读取的页数没变，但很多页都没有被充分利用。

这种迹象组合基本就可以判断页利用率出了问题。前面说过，B+Tree的叶子页如果因为分裂导致平均填充率只有60%-70%，同样读取100行数据的代价，会比正常结构多读约50%的页。数据库页面读入内存后，针对该页内有效记录的处理时间不变，但物理页的IO次数增加，扫描范围扩大。

2.3 别忘了DELETE也有碎片贡献

大量写入场景往往不是单纯的INSERT，UPDATE和DELETE一般也伴随而来。DELETE在InnoDB中默认不会立刻物理释放空间，而是在页内把记录标记为“已删除”，这样做的目的是为了支持MVCC。但大量被标记删除的记录要么等purge线程清理，要么在页内形成不可用空洞。即使purge最终处理了这些版本，页内的物理空间也可能无法被连续利用，因为新插入的记录需要按顺序放在合适的位置，而不是简单地填充到已删除记录留下的空洞里。

所以在碎片整理前，最好先观察history list length和purge线程是否正常。如果因为长事务导致undo不能purge，记录版本堆积，这时候看到索引体积膨胀，第一反应不应该是整理碎片，而是先处理长事务。先用SELECT * FROM information_schema.innodb_trx\G查一下长时间未提交的事务，再把碎片整理排上日程。

3. 不要凭感觉判断碎片，量化指标才是决策依据

“该不该做索引碎片整理”不能看业务方觉得卡不卡，更不能拍脑袋说“每个月整理一次”。要用可量化的指标判断。

3.1 五张信息表与一个重建率的估算思路

定位MySQL碎片，主要看这些视图和命令：

SHOW TABLE STATUS LIKE '表名'里的Data_free字段：表示该表所在表空间中空闲扩展页的字节数，严格说不是碎片总量，但可以反映整体的空间浪费水平。
information_schema.tables中的data_free，可以快速排序出全库“体检名单”。
information_schema.innodb_sys_tablespaces / innodb_sys_indexes：能看到每个索引的页面数、根页等信息，但需要MySQL版本支持，普通版本比较复杂。
performance_schema中关于InnoDB页读写的统计：如果能观察到物理读次数明显多于逻辑读应该需要的水平，那就说明每次扫描要读额外页。

实际操作中我很少直接算“碎片率百分比”，因为官方没有一个明确的碎片率字段。一般用两种估算方式：

sql复制-- 方式1：通过表状态估算可回收空间比例
SELECT 
    table_name,
    ROUND(data_length / 1024 / 1024, 2) AS data_mb,
    ROUND(index_length / 1024 / 1024, 2) AS index_mb,
    ROUND(data_free / 1024 / 1024, 2) AS free_mb,
    ROUND(data_free / (data_length + index_length) * 100, 2) AS fragmented_pct
FROM information_schema.tables
WHERE table_schema = 'your_db'
ORDER BY data_free DESC;

sql复制-- 方式2：直接看索引的“实际使用”和“理论使用”对比
-- 假设知道总行数rows和行平均长度avg_row_length
SELECT 
    t.table_name,
    t.table_rows,
    t.avg_row_length,
    t.index_length / 1024 / 1024 AS index_mb,
    ROUND((t.index_length / 1024 / 1024 * 1024) / NULLIF(t.table_rows * t.avg_row_length, 0), 2) AS estim_index_overhead_ratio
FROM information_schema.tables t
WHERE t.table_schema = 'your_db' AND t.table_rows > 100000
ORDER BY estim_index_overhead_ratio DESC;

第一种方法里的fragmented_pct如果长期超过30%到50%，并且表持续高速写入，通常就值得做一次整理。第二种方法的思路是，把索引占用与数据本身占用对比，如果索引文件是数据行的好几倍，而实际业务查询并没有那么多复杂的组合索引，就要认真分析是碎片、冗余索引还是统计信息滞后。

注意：information_schema.tables里的table_rows只是估算值，来自索引统计信息抽样，不一定精确。用这些SQL做排序和观察趋势可以，不能当作精确结论。

3.2 一份可以放进监控的“索引膨胀巡检SQL”

碎片整理不应该是救火行为，最好平时就放在巡检脚本里。下面这个SQL适合每周跑一次，把结果输出到文本或监控平台：

sql复制SELECT
    table_schema AS db,
    table_name AS tbl,
    ROUND(index_length / 1024 / 1024, 2) AS index_mb,
    ROUND(data_length / 1024 / 1024, 2) AS data_mb,
    ROUND(data_free / 1024 / 1024, 2) AS data_free_mb,
    ROUND(index_length / NULLIF(data_length, 0), 2) AS idx_data_ratio,
    ROUND(data_free / NULLIF(index_length + data_length, 0) * 100, 2) AS frag_pct
FROM information_schema.tables
WHERE table_schema NOT IN ('mysql', 'information_schema', 'performance_schema', 'sys')
  AND table_type = 'BASE TABLE'
HAVING frag_pct > 20 OR idx_data_ratio > 3
ORDER BY data_free_mb DESC
LIMIT 50;

筛选逻辑是这样的：frag_pct超过20%代表有整理空间，idx_data_ratio超过3意味着二级索引体积远超表数据，需要关注是否冗余——但前者才是碎片整理的直接触发因子。

相比直接用ALTER TABLE暴力整理，更重要的是监控它的趋势。如果一张表的数据量没有剧烈变化，而index_length每周都在涨，说明碎片在以稳定的速度累积。这时候就可以预判它的整理周期，而不是等慢查询报警才想起来处理。

3.3 别被`Data_free`骗了：它并不等于你立刻能回收的空间

Data_free单位是字节，但它统计的是表空间中空闲扩展区的总量，并不完全是逻辑碎片。比如一个表刚DELETE掉大量数据，Data_free会显得很大，但那些空间可能分布在表的不同区段，InnoDB只有在后续插入需要空间时才会优先复用。反向的情况也有：表空间自动扩展后，有可能整体空间并没有缩小，但Data_free始终不大，因为空闲空间被存储在.ibd文件更靠后的位置。

MySQL没有像某些商业数据库一样的“压缩表”命令，要真正回收空间，必须重建表。理解这一点之后，就不会为了追求Data_free归零而频繁做无谓的整理。

4. 索引碎片整理的三种主流路线：代价、适用场景与坑

碎片整理到底怎么做，有三种常见路线：直接用ALTER TABLE触发重建，使用在线DDL工具pt-online-schema-change，或者用OPTIMIZE TABLE。三者的本质都是重建表或索引，但细节差别很大。

4.1 ALTER TABLE ENGINE=InnoDB：最直接，但要评估窗口

ALTER TABLE your_table ENGINE=InnoDB; 这条命令会强制InnoDB重建整张表，属于经典的复制表方式。在MySQL 5.6以后，这条命令默认走Online DDL的INPLACE算法，但具体是INPLACE还是COPY，取决于表是否有全文索引等因素。如果触发了COPY模式，等于创建一个临时表，把所有数据重放一遍，再交换表名。

我建议执行前先看执行计划：

sql复制EXPLAIN ALTER TABLE your_table ENGINE=InnoDB;

注意看Extra列，如果是Creating index，说明它有重建二级索引的动作；如果是Copy to tmp table，说明连表数据本身都会复制一遍。大多数场景下，在线DDL允许并发DML，但也不会完全没有锁。碎片较多的表执行这条命令时，会重新组织聚簇索引的页，把相邻逻辑数据尽量放在相邻物理页上，然后每个二级索引也会重建。本质上这是成本很高的操作，IO和CPU都会有一个尖峰。

我不建议在业务高峰直接执行。至少要预留以下条件：

磁盘空闲空间至少占表文件大小的1倍以上（因为重建过程需要临时空间）。
在主库执行时，确认从库延迟余量。
如果表超过50GB，直接用ALTER TABLE风险偏大，要引入在线工具。
如果表上存在外键，Online DDL期间外键检查带来的锁影响会更明显，建议先评估。

性能方面，如果表只有几千万行，整理后二级索引体积能缩到原来的60%左右，查询效率提升通常立竿见影。但要注意，整理完后的前一段时间，buffer pool里缓存的是重新组织的索引页，冷热状态和旧结构完全不同，部分SQL可能出现短暂波动。

4.2 pt-online-schema-change：控制主从延迟的教训

超过一定数据量后，我更推荐用percona-toolkit里的pt-online-schema-change。它的原理是创建一张新表，在旧表上建立触发器，把在线写入同步到新表，然后通过chunk方式逐段拷贝数据。这样不需要一次性锁表，理论上可以在业务运行期间执行。

但“不锁表”不等于“没有压力”。如果chunk大小设置不当，从库延迟会飙升。我有一张约2亿行的流水表，一开始用默认chunk size，结果大批量写入期间主库IO直接被打满。后来用如下参数控制：

bash复制pt-online-schema-change \
  --alter "ENGINE=InnoDB" \
  --host=localhost \
  --user=root \
  --password=*** \
  --max-lag=5 \
  --chunk-size=500 \
  --chunk-time=1 \
  --critical-load=Threads_running=100 \
  --max-load=Threads_running=50 \
  D=your_db,t=your_table \
  --execute

参数含义拆解：

--max-lag=5：从库复制延迟超过5秒时，工具自动暂停拷贝。
--chunk-size=500：每次复制500行。如果主键是UUID，这个数字很可能需要调低到200甚至100，因为UUID主键的随机访问模式会让每行拷贝产生多次随机IO。
--critical-load=Threads_running=100：当并发线程超过100时强制退出。
--chunk-time=1：每个chunk的执行时间目标为1秒而不是严格按行数切分。

最大的坑在于：工具在拷贝完成后会执行一次RENAME TABLE，期间会有一瞬间的元数据锁。对绝大部分业务而言这个时间段可以忽略，但如果连接池里存在长时间未提交事务，RENAME会等待全局锁释放，拖慢整个流程。执行前最好检查是否有长事务：

sql复制SELECT trx_id, trx_started, trx_rows_modified
FROM information_schema.innodb_trx
ORDER BY trx_started;

4.3 OPTIMIZE TABLE与ALTER TABLE的区别

OPTIMIZE TABLE your_table; 在InnoDB中的实现，相当于ALTER TABLE ... FORCE，也就是重建表。MySQL 5.7以后，如果表上没有全文索引，OPTIMIZE TABLE也能使用Online DDL，但底层仍然是一次表重建。

如果只想整理一个二级索引而不动全表，目前InnoDB没有专门命令支持“单独重建索引”。你可以先用ALTER TABLE ... DROP INDEX再重新ADD INDEX，但代价是索引重建期间的写入和查询都会受影响，而且在重建完成前，这个索引的查询优化器选不到。这种方式适合特别小的索引，大表还是全表重建更稳妥。

另外，MySQL 8.0引入了ALTER TABLE ... ALGORITHM=INSTANT能力，但只支持新增列等操作，不支持碎片整理，别指望它能帮上忙。

5. 一次碎片整理的重现场景：优化前和优化后的真实数据对比

为了更直观地体现碎片整理的作用，我把之前一张订单流水表的优化过程完整复盘一下。

5.1 优化前：索引体积膨胀到正常值的2.3倍

表结构设计如下：

sql复制CREATE TABLE `order_flow` (
  `flow_id` varchar(32) NOT NULL COMMENT '流水号',
  `order_no` varchar(64) NOT NULL COMMENT '订单号',
  `user_id` bigint NOT NULL,
  `status` tinyint NOT NULL DEFAULT '0',
  `create_time` datetime NOT NULL,
  `update_time` datetime NOT NULL,
  PRIMARY KEY (`flow_id`),
  KEY `idx_user_id` (`user_id`),
  KEY `idx_create_time` (`create_time`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这张表每天通过消息队列写入约200万条流水，由于flow_id由业务侧生成且分散，不是顺序写入，同时status字段会被多次UPDATE。持续写入45天后，SHOW TABLE STATUS的数据如下：

字段	优化前数值
行数（估算）	约6800万
data_length	11.2GB
index_length	15.8GB
data_free	2.1GB
avg_row_length	约180字节

正常状态下，这张表的index_length和数据量之比大约在1.0到1.2之间。此时index_length达到data_length的1.4倍，而且因为flow_id是32位varchar，每行主键本身很大，索引总量已经明显超出合理范围。慢查询里出现这样的SQL：

sql复制SELECT flow_id, order_no, status, create_time
FROM order_flow
WHERE create_time BETWEEN '2024-05-01 00:00:00' AND '2024-05-01 23:59:59'
  AND status = 1
ORDER BY create_time
LIMIT 200;

执行计划显示走idx_create_time，预计扫描约18万行，但实际执行耗时从之前的50ms涨到280ms。原因是二级索引叶子页大量空洞，规划扫描的page数量远超实际有效数据量。

5.2 优化过程：锁竞争比碎片本身更棘手

我选择在凌晨2点执行ALTER TABLE order_flow ENGINE=InnoDB, ALGORITHM=INPLACE, LOCK=NONE;，但过程中踩了一个典型的坑：业务侧有一个定时任务，每分钟会更新一批status字段，且其中部分事务持续时间较长。DDL虽然声明LOCK=NONE，但真正执行到结束阶段的表定义变更时，还是需要等待所有事务释放元数据锁。结果这个DDL在最后阶段卡住，等待了一个“长事务”约40分钟。

之后改用pt-online-schema-change重跑，先把长事务KILL掉（不要在生产环境随意杀，先和研发确认），再按chunk-size=300重新整理。整个重建过程耗时约1小时20分钟，主库CPU峰值约65%，从库延迟最大到8秒，可接受范围内。

5.3 优化后：二级索引体积从15.8GB降到6.4GB

整理后的统计结果和查询表现：

指标	优化前	优化后
index_length	15.8GB	6.4GB
data_free	2.1GB	约100MB
同一SQL执行时间	280ms	45ms
扫描page数量（通过performance_schema观察）	约4000+	约1600
插入延迟高峰	约40ms	约12ms

我特别关注了第一个慢查询的表现：执行时间从280ms降到45ms，扫描行数不变，但逻辑读降了约50%，物理读降幅更大。索引体积从15.8GB降到6.4GB，对InnoDB buffer pool的压力也缓解了，相当于同样的缓冲池可以缓存更多有效索引页。

这次优化的“收益”并不只在慢查询减少上。第二天白天的全表统计类报表任务平均耗时从35分钟降到20分钟以内，因为这类任务通常大幅度扫描索引，碎片整理后页读效率提高，效果非常明显。

6. 从一次账期中断到日常巡检：如何避免每三个月紧急处理一次

整理完碎片，业务恢复流畅，但如果不从源头解决碎片产生机制，三个月后大概率复发。下面几个策略是我长期实践后形成的维护组合。

6.1 碎片合入阈值：不是所有碎片都需要立即整理

碎片整理是拿长时间的IO压力和锁风险换空间与查询效率，必须设定明确的阈值，避免过度整理。

我在不同环境里常用的阈值组合是：

单表数据量小于1GB时，即便碎片率到50%，也优先观察，因为重建瞬间成本可能比碎片本身影响更大。
单表数据量在1GB到50GB之间，当一个索引或表估算碎片率超过30%，并且对应慢查询逐渐增加时，启动整理。
单表超过50GB，碎片率超过30%且业务有明显的范围扫描，会在资源充沛的窗口用pt-osc处理。
重要表可以配合binlog或备份恢复演练来验证，确保重建期间万一出现问题，可以快速回滚策略。

阈值不是死的。索引相对读取频繁、写入少的表，即使碎片率不高如果出现明显查询退化也可考虑整理；而那些写入极频繁、读取简单的小表，碎片率很高但重建后很快又会累积，不如把精力放在缩小主键、调整写入模式上。

6.2 从源头降低碎片增长速度：主键和索引设计是第一道防线

大量写入场景下，主键设计直接影响碎片速率。

尽量用自增ID或有序雪花ID做主键，而不是全局UUID字符串。如果业务必须暴露业务单号，可以拆成两层：内部自增主键+业务唯一键。这样聚簇索引内部写入基本是追加模式，页分裂频率会明显下降。
二级索引大小控制在“够用”的范围内。每增加一个二级索引，每次写入/更新都要额外维护索引页；一个长期写入的表上堆了七八个很少使用的索引，表面上查询很快，实际上拖慢了所有写入和索引维护。最好是周期性地用sys.schema_unused_indexes和performance_schema统计索引使用情况，把长期没有读的索引删掉。
对更新频率极高的字段建索引要非常谨慎。status = 0 -> 1 -> 2这类状态字段的频繁变化会让二级索引页不断delete+insert，如果离散不是特别高且查询压力不大，宁可去掉或改成覆盖查询能解决的复合索引。

这相当于把问题从“索引坏了怎么修”往前推了一步：“索引什么时候不容易坏”。我踩过几次坑的经验是，如果一张表的核心主键是随机字符串，同时还有多个二级索引，那么无论你怎么整理索引碎片，效果最多保持几周。索引体积又会回到膨胀状态，必须设计层面干预。

6.3 一个被很多人忽视的路径：批量写入改成按主键排序批量提交

这个不是MySQL层面的整理了，而是在应用写入侧做优化。如果数据量非常大，可以从消息队列消费后，先在应用内存里积攒几百条或几千条数据，按主键排序后批量INSERT。这样InnoDB在写入聚簇索引时，大概率会按页递增的方式推进，页分裂概率大幅降低，二级索引的插入也更有局部性。

具体实现上可以这样：

python复制# 伪代码：批量写入前按主键排序
batch = []
for msg in consumer:
    batch.append(parse(msg))
    if len(batch) >= 1000:
        batch.sort(key=lambda x: x['id'])  # 按主键/聚簇键排序
        insert_many_with_executemany(batch)
        batch.clear()

业务允许的情况下，把数据库的写入模式从“来一条插一条”改成“攒一批排好再插”，能有效降低页分裂频次和碎片增长速度。我曾经为一个数据接入服务做过这个改造，效果比定期跑索引整理好得多，因为从源头减少了页分裂。

6.4 巡检脚本与复盘机制：一次事故教会我的事

最后说说我把索引碎片检查纳入了日常巡检体系的实践。

每周二的凌晨，会执行一次以3.2节的巡检SQL为核心的脚本，把结果发到值班群，选出top10膨胀表。每周的数据库评审会上看趋势，如果某张表的index_length_week递增超过10%，就要求管理员或研发一起看原因。

另外一个容易被忽视的细节是：大版本升级、硬件迁移、备份恢复之后，都要重新评估一次碎片情况。因为这些运维操作通常会重放大量数据，页的物理顺序可能被改变。以前我遇到过这样的案例：一套库用逻辑备份恢复后，一张2亿行的表查询性能比恢复前还差，排查后发现备份恢复过程把所有索引页打乱了，最后做了一次全量表重建才恢复性能。从那次之后，我把“恢复后索引体检”也写进了运维手册。

如果把整个思路浓缩成一句经验：碎片整理不是数据库出了故障后的灵丹妙药，它更像是运维流程里的一把活动扳手，关键是你要有一套能判断“什么时候该拧、拧到什么程度”的机制。对写入密集型的库来说，真正的护城河永远是健康的索引设计和有序的写入模式，整理碎片只是把上游设计留下的问题兜底解决掉而已。每次做完大表整理，我都会顺手查看过去一个月的binlog写入分布和慢查询趋势，把下一次可能出问题的表提前圈出来。基础工作做到这个程度，生产环境的“救火时刻”会越来越少。