analyze table能修复因统计失真导致的索引误选，前提是确认基数不准：explain中rows预估与实际行数差一个数量级、show index中cardinality远低于count(distinct列)，且排除函数使用、隐式转换、统计未持久等干扰因素。
ANALYZE TABLE 能直接修复因统计失真引发的索引误选，但前提是问题根源确实是基数不准——不是所有“走错索引”都该用它。
怎么确认真是统计信息错了
别一慢就跑 ANALYZE TABLE。先看执行计划里 rows 预估是否离谱：比如 WHERE city_id = 565 实际只返回 200 行，但 EXPLAIN 显示 rows=80000000，这就是典型基数崩了。再查 SHOW INDEX FROM table_name，对比 CARDINALITY 和真实去重数（SELECT COUNT(DISTINCT city_id) FROM table_name），差一个数量级基本能坐实。
常见干扰项包括：
- 查询里用了函数，如
WHERE DATE(log_dt) = '2024-01-01'，索引直接失效，ANALYZE无意义 -
city_id是INT，但传参是字符串'565'，触发隐式转换，优化器不敢走索引 -
innodb_stats_persistent = OFF且innodb_stats_on_metadata = OFF，统计信息压根不持久，ANALYZE后可能下次查又回退
ANALYZE TABLE 执行时要注意什么
它不是“刷新缓存”，而是重新采样索引页、重算 CARDINALITY 和 ROWS。默认只采样约 10–20 个页，对大表或数据倾斜严重的情况，精度可能仍不够。
关键控制点：
- 仅对
InnoDB表有效；MyISAM得用myisamchk -a - 执行期间会加读锁，大表务必避开高峰期，否则阻塞写入
- 想提高精度，可临时调大采样页数：
SET GLOBAL innodb_stats_persistent_sample_pages = 100，再执行ANALYZE TABLE - 如果
innodb_stats_persistent = ON（推荐），统计结果会落盘，后续自动更新阈值由innodb_stats_auto_recalc控制
为什么 ANALYZE 后还是没换索引
执行完 ANALYZE TABLE，EXPLAIN 的 key 字段没变？优先排查这三件事：
- 检查是否真的生效：查
information_schema.STATISTICS表，确认CARDINALITY值已变动，而非只是时间戳更新 - 确认没有被
FORCE INDEX或USE INDEX硬编码覆盖，这类提示会完全绕过优化器决策 - 是否存在更优的覆盖索引？比如
WHERE a = ? AND b = ?时，(a,b)复合索引比单列a更优，优化器可能因此放弃你期待的那个
别指望一次 ANALYZE 一劳永逸
统计不准这事本身不报错、不告警，安静地拖垮性能。真正稳定的应对方式，是把它变成运维动作：把 ANALYZE TABLE 加入低峰期巡检脚本，配合监控 CARDINALITY 波动（比如某天突降 90%），提前干预。另外，对高频变更的大表，建议设为 innodb_stats_persistent = ON 并打开 innodb_stats_auto_recalc = ON，让系统在数据变更超阈值时自动补采样——但别依赖它完全替代手动分析，尤其上线新索引或批量导入后。
