MySQL 统计信息更新统计信息后判断计划变化的实现方法

MySQL 统计信息更新后，不能只看 ANALYZE TABLE 返回成功就断定执行计划变了。可靠的判断方法是固定同一条 SQL、参数和会话条件，先保存更新前的 EXPLAIN 与索引基数，再执行统计信息更新，最后用同一口径对比 access_type、key、rows、filtered 和成本字段。

官方地址：https://dev.mysql.com/doc/refman/8.4/en/analyze-table.html

本文只讨论统计信息与优化器的关系，不把示例输出当作某个真实库的结果。文章中的图是静态说明图，不是数据库控制台截图。

保存同一查询的更新前基线

先选一条能稳定复现问题的查询，固定数据库、参数、事务隔离级别和优化器开关。不要一边更换 WHERE 条件，一边比较计划，否则数据选择性变化会和统计信息变化混在一起。

-- 记录更新前的计划；示例表名和条件应替换成实际业务查询
EXPLAIN FORMAT=JSON
SELECT order_id, created_at
FROM orders
WHERE user_id = 10086 AND status = 'paid'
ORDER BY created_at DESC
LIMIT 20;

-- 查看索引基数，重点保留同一时点的 cardinality 记录
SHOW INDEX FROM orders;

-- 需要复核耗时时，只比较同一参数和同一数据快照
SELECT COUNT(*) AS sample_rows
FROM orders
WHERE user_id = 10086 AND status = 'paid';

基线至少保存四类信息：访问类型和候选索引、估算行数、过滤比例，以及查询本身的参数口径。SHOW INDEX 中的基数是优化器可用的统计线索，不等同于实际行数；它变化了，也不代表最终访问路径一定变化。

执行 ANALYZE TABLE 并确认更新对象

ANALYZE TABLE orders; 主要更新表的键分布分析；MySQL 文档说明，它会返回 Table、Op、Msg_type 和 Msg_text，所以先记录返回信息，再进入前后计划比较。

-- 更新表级键分布；执行窗口要避开业务高峰
ANALYZE TABLE orders;

-- 只有列值分布会影响选择性判断时，才维护直方图
ANALYZE TABLE orders
  UPDATE HISTOGRAM ON status, user_id
  WITH 64 BUCKETS;

-- 查看列级直方图是否存在以及更新时间信息
SELECT SCHEMA_NAME, TABLE_NAME, COLUMN_NAME, HISTOGRAM
FROM INFORMATION_SCHEMA.COLUMN_STATISTICS
WHERE TABLE_NAME = 'orders';

表级键分布和列级直方图是两种不同证据。直方图用于帮助优化器估算列值比较的选择性，并不是每条查询都会使用。只为了解决索引基数不准而盲目给所有列生成直方图，反而会增加维护面。

更新后做同口径计划对照

更新后重复执行同一条 EXPLAIN，把结果按字段对照，而不是只比较 JSON 文本是否不同。最有价值的是访问类型、实际使用的 key、估算 rows、filtered、连接顺序和 cost_info。字段发生变化，说明优化器估算或选择发生了变化；是否改善仍需在同一参数集下观察实际耗时。

-- 更新后使用完全相同的 SQL，避免引入新的变量
EXPLAIN FORMAT=JSON
SELECT order_id, created_at
FROM orders
WHERE user_id = 10086 AND status = 'paid'
ORDER BY created_at DESC
LIMIT 20;

-- TREE 格式便于阅读连接顺序和访问路径
EXPLAIN FORMAT=TREE
SELECT order_id, created_at
FROM orders
WHERE user_id = 10086 AND status = 'paid'
ORDER BY created_at DESC
LIMIT 20;

可以把更新前后保存为两份带时间戳的计划快照，做一张小表：key 是否变化、rows 是否明显变化、是否出现全表扫描、连接顺序是否变化、实际耗时是否同向变化。若只有估算值变了而路径没变，这是一次统计修正；若路径变了但耗时变差，应先保留证据，不要立即把问题归因于索引缺失。

计划未变或变差时的处理方案

计划没有变化并不表示 ANALYZE TABLE 失败：原来的估算可能已经足够，或者新统计信息没有改变成本比较结果。计划变差时，按以下顺序排查：

• 确认更新前后查询文本、参数、数据范围和会话优化器开关一致。
• 确认表使用持久化优化器统计；非持久化统计在重启或重新计算后可能得到不同估算。
• 确认直方图只用于合适的列值比较，且 INFORMATION_SCHEMA.COLUMN_STATISTICS 中记录的是目标列。
• 保留更新前后的计划、SHOW INDEX、命令返回和实际耗时，再决定调整采样参数、删除不合适的直方图或进入索引设计。

回滚思路也应记录在变更单里：先停止重复刷新，恢复到可解释的统计配置；若只是新增直方图造成判断偏移，可以使用 ANALYZE TABLE ... DROP HISTOGRAM ON ... 移除对应列的直方图。不要把“计划变了”直接等价成“系统一定更快”，真正的验收要回到同一查询、同一参数和同一业务指标。

常见问题

ANALYZE TABLE 执行成功，为什么 EXPLAIN 没变化？ 可能是旧统计已经足够准确，也可能是成本模型在更新前后仍选择同一路径。检查估算字段与统计返回，比只看 key 更可靠。

rows 变了但查询变慢，应该马上加索引吗？ 不应该。先确认参数、缓存、并发和数据范围一致，再判断是估算变化还是实际资源争用；统计信息问题和索引问题要分开处理。

直方图能替代索引吗？ 不能。直方图是优化器的列分布信息，索引仍决定可用的访问结构，两者解决的是不同层面的问题。

小结：先固定查询并保存基线，再更新对应层级的统计信息，最后用同一 SQL 对照计划字段和实际指标。只有证据链完整，才能判断统计信息是否改变了计划，以及这次变化是否值得保留。