MySQL ANALYZE TABLE 怎样更新 InnoDB 索引统计信息

如果一条查询昨天还走索引，今天却突然扫描了大量记录，先不要马上改 SQL 或重建索引。InnoDB 的索引基数和表数据分布变化后，优化器手里的统计信息可能已经不能代表当前数据。此时可以先用 ANALYZE TABLE 重新采集统计信息，再用 EXPLAIN 对照计划。

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

这篇文章只解决“怎样刷新 InnoDB 索引统计信息”这个问题。ANALYZE TABLE 会更新统计信息，但不会替你创建索引，也不保证刷新后计划一定改变；最终要把执行状态、统计变化和查询计划分别核对。

先判断：问题像统计信息失真吗

EXPLAIN 中的 rows 是优化器对需要检查行数的估算，不是一次精确计数。如果表经历了大量插入、删除、批量导入，或者数据分布发生明显倾斜，估算与实际访问量可能拉开差距。这个现象适合把“刷新统计信息”作为低风险排查动作。

我们先保存一份刷新前的计划。下面的示例只读计划，不执行查询；注释说明了为什么同时保留访问类型、索引和行数估算。

-- 先保存刷新前的访问路径、索引选择和行数估算
EXPLAIN FORMAT=TREE
SELECT order_id, customer_id, created_at
FROM orders
WHERE customer_id = 10086
  AND created_at >= '2026-10-01';

如果刷新前后 rows 估算更贴近当前数据，或访问类型从全表扫描恢复为索引范围扫描，说明统计信息可能确实参与了这次决策。若 SQL 本身对列做了函数运算，或谓词没有可用索引，刷新统计信息就不是根治方案。

用 ANALYZE TABLE 刷新单表统计信息

最常见的写法是指定表名。语句成功返回后，只能说明刷新动作被接受并完成，不能直接推断某个查询一定会换计划。

-- 刷新单表的 InnoDB 索引统计信息
ANALYZE TABLE orders;

-- 需要时一次刷新多个表，但要注意锁等待和业务负载
ANALYZE TABLE orders, order_items;

如果只想覆盖分区表的部分分区，可以指定 PARTITION；这样读者能把采集范围和故障表的数据变化对应起来。

-- 只刷新发生大批量变更的分区，避免误把整张表当作排障范围
ANALYZE TABLE orders PARTITION p202610, p202611;

InnoDB 的统计信息用于估算索引选择性和访问成本。刷新对象应当是发生数据变化且参与查询的表，而不是把所有表定时无差别执行一遍。对高峰期大表，先评估资源、等待和复制拓扑，再安排窗口。

刷新后怎样确认结果

确认时分三层看：第一层是语句返回状态，第二层是统计信息是否重新采集，第三层是目标查询的计划是否更合理。不要把三层混成“执行成功等于性能变好”。

-- 用表分析结果确认语句返回状态；这里不把它当作性能结论
ANALYZE TABLE orders;

-- 再检查目标查询的访问类型、实际索引和行数估算
EXPLAIN FORMAT=TREE
SELECT order_id, customer_id, created_at
FROM orders
WHERE customer_id = 10086
  AND created_at >= '2026-10-01';

如果环境支持 EXPLAIN ANALYZE，它会实际执行语句并提供迭代器层面的耗时、返回行数和循环次数，适合比较“估算 rows”和“实际 rows”。它不是刷新统计信息的替代品，而且会执行目标语句，写语句必须先确认业务影响。

-- 该语句会执行 SELECT，用于对照估算与实际迭代器信息
EXPLAIN ANALYZE
SELECT order_id, customer_id, created_at
FROM orders
WHERE customer_id = 10086
  AND created_at >= '2026-10-01';

常见不生效原因

第一，权限或对象范围不对。执行账号需要具备相应的表操作权限；分区语法也必须与表的实际分区定义匹配。先看错误信息和对象名，不要把权限失败当成统计信息没有变化。

第二，刷新成功但计划不变。这可能表示原计划本来就是成本更低的选择，也可能是估算误差来自相关列、数据倾斜、谓词写法或缺少合适索引。ANALYZE TABLE 只更新统计信息，不会重写查询。

第三，刚刷新又被数据变化覆盖。如果表持续高频写入，采集结果很快又不代表业务时点。此时应固定样本查询，记录刷新前后的 EXPLAIN，并结合业务低峰安排，而不是循环执行刷新语句。

第四，把估算和实测混为一谈。EXPLAIN 主要回答优化器准备怎样执行；EXPLAIN ANALYZE 会执行查询并提供实际迭代器信息。两者用途不同，比较时要保留相同 SQL、参数和数据状态。

总结与常见问题

排查 MySQL 查询计划异常时，可以先保存目标查询的 EXPLAIN，再对发生明显数据变化的 InnoDB 表执行 ANALYZE TABLE，最后重新查看计划；需要验证估算误差时，再谨慎使用会执行查询的 EXPLAIN ANALYZE。刷新成功不等于索引一定改变，计划不变也不等于语句失败。

ANALYZE TABLE 会创建新索引吗？不会，它只负责更新表和索引相关的统计信息。

为什么刷新后 rows 还是不准？rows 是优化器估算，仍会受数据分布、相关列、谓词写法和统计采样影响，不能当作精确行数。

可以把 ANALYZE TABLE 放进高频定时任务吗？应先评估表大小、写入压力、等待和复制影响，按目标表和业务窗口制定计划，不建议无差别高频执行。