mysql的查询优化器在选择索引时，会基于表的统计信息来评估不同执行计划的成本，最终选择它认为成本最低的方案。如果统计信息没有及时更新，和实际数据分布偏差较大，就可能出现索引走错的情况，比如明明有更高效的索引却选择了全表扫描，或者选了区分度更低的索引。
索引走错的常见原因
mysql的索引统计信息主要存储的是表的行数、索引的基数（不同值的数量）等信息，这些信息不会实时更新，而是在特定场景下才会触发更新：
- 表的数据量发生较大变化，比如新增、删除大量数据后，没有触发统计信息更新
- 手动修改了表的统计信息相关参数，导致统计信息不符合实际数据分布
- 长期运行的表，数据分布逐渐变化，旧的统计信息已经无法反映当前情况
当统计信息不准确时，优化器计算的成本就会出现偏差，比如某个索引的实际区分度很高，但统计信息里显示的基数很低，优化器就会认为走这个索引的成本更高，从而放弃使用它。
AnalyzeTable的作用
AnalyzeTable是mysql提供的用于更新表统计信息的命令，执行该命令后，mysql会重新扫描表的数据，计算最新的行数、索引基数等统计信息，并更新到系统表中，让优化器可以获取到准确的数据分布信息。
需要注意，AnalyzeTable会对表加一个读锁，在命令执行期间，表可以正常读取，但是写入操作会被阻塞，所以对于线上大表，需要在业务低峰期执行该操作。
使用AnalyzeTable解决索引走错问题
1. 确认索引走错的情况
首先可以通过EXPLAIN命令查看查询的执行计划，确认是否真的出现了索引走错的情况。比如我们有一张用户表user，在age和name字段上分别有索引，查询语句如下：
EXPLAIN SELECT * FROM user WHERE age = 20 AND name = '张三';
如果执行计划里显示的key字段是NULL或者不是我们预期的age和name的组合索引，就说明出现了索引走错的情况。
2. 执行AnalyzeTable更新统计信息
确认索引走错后，可以对对应的表执行AnalyzeTable命令，语法如下：
ANALYZE TABLE user;
执行后会返回结果，显示表名、操作类型、状态等信息，如果状态是OK，说明统计信息更新成功。
3. 再次验证执行计划
更新完统计信息后，再次执行EXPLAIN命令查看执行计划，此时优化器通常会选择更合适的索引：
EXPLAIN SELECT * FROM user WHERE age = 20 AND name = '张三';
如果此时key字段显示为我们预期的索引，说明问题已经解决。
注意事项
- AnalyzeTable对于InnoDB和MyISAM引擎的表都有效，但是InnoDB的默认统计信息更新策略是持久化的，执行AnalyzeTable会更新持久化的统计信息
- 如果表的数据量非常大，执行AnalyzeTable可能会消耗较多的时间和资源，建议提前评估影响
- 如果频繁出现索引走错的情况，可以考虑调整
innodb_stats_auto_recalc参数，开启自动统计信息更新，当表的数据变化量超过10%时，会自动触发统计信息更新
其他相关优化建议
除了使用AnalyzeTable更新统计信息外，还可以通过以下方式减少索引走错的概率：
- 定期维护表的统计信息，尤其是数据变化频繁的表
- 合理设计索引，避免创建过多冗余索引，减少优化器的选择成本
- 如果某些查询的索引选择问题无法通过更新统计信息解决，可以使用
FORCE INDEX强制指定索引，但是这种方式不够灵活，建议优先通过更新统计信息解决
mysql索引AnalyzeTable统计信息修改时间：2026-06-12 17:39:27