mysql的查询优化器依赖统计信息来选择最优的查询执行计划，当表数据发生大量增删改操作后，统计信息可能过时，导致优化器选择低效的执行计划。此时需要手动刷新统计信息，AnalyzeTable是mysql提供的用于更新表统计信息的核心命令。
手动刷新优化器统计信息的操作方式
手动刷新统计信息最常用的方式就是执行AnalyzeTable命令，该命令可以针对单个表或者多个表进行统计信息更新，执行语法如下：
-- 分析单个表 ANALYZE TABLE 表名; -- 分析多个表，表名之间用逗号分隔 ANALYZE TABLE 表1, 表2, 表3;
执行该命令后，mysql会返回每个表的分析结果，常见的返回状态有以下几种：
- OK：统计信息更新成功，没有异常
- Table is already up to date：表的统计信息已经是最新状态，不需要更新
- Error：执行过程中出现错误，需要检查表结构或者权限
除了AnalyzeTable命令之外，也可以通过修改innodb_stats_auto_recalc参数开启自动统计信息更新，但是自动更新存在延迟，手动执行AnalyzeTable可以即时生效，适合在大量数据变更后快速修正统计信息。
AnalyzeTable命令的执行原理
不同存储引擎的处理差异
AnalyzeTable的执行逻辑和表的存储引擎相关，mysql常用的存储引擎是InnoDB和MyISAM，两者的统计信息更新机制存在明显区别。
MyISAM存储引擎的处理逻辑
MyISAM的统计数据存储在磁盘的.MYI索引文件中，执行AnalyzeTable时，会扫描整个表的索引，统计每个索引的不同值数量、索引基数等信息，然后将这些统计信息写入.MYI文件，后续优化器读取该文件获取统计信息。这种方式的统计结果相对准确，但是扫描全表会带来一定的IO开销。
InnoDB存储引擎的处理逻辑
InnoDB的统计信息分为持久化统计信息和非持久化统计信息，默认开启持久化统计信息，相关数据存储在mysql.innodb_table_stats和mysql.innodb_index_stats系统表中。
执行AnalyzeTable时，InnoDB不会直接扫描全表，而是通过采样的方式获取统计信息：
- 根据
innodb_stats_persistent_sample_pages参数设置的采样页数，从表的聚簇索引中随机采样指定数量的页 - 统计采样页中的数据行数、每个索引的不同值数量、索引的基数等信息
- 将采样得到的统计信息计算后更新到持久化系统表中，同时更新内存中的统计信息缓存
采样的方式大大降低了统计信息更新的开销，但是统计结果可能存在一定误差，采样页数越多，统计结果越准确，但是开销也越大。可以通过调整innodb_stats_persistent_sample_pages参数平衡统计准确性和更新开销，默认值为20。
统计信息的更新范围
AnalyzeTable只会更新表的索引统计信息，不会重建表或者修复索引结构，和OPTIMIZE TABLE命令的作用不同，后者会整理表碎片、重建表，开销远大于AnalyzeTable。如果只是统计信息过时导致查询变慢，优先使用AnalyzeTable即可，不需要执行OPTIMIZE TABLE。
使用注意事项
执行AnalyzeTable时需要注意以下几点：
- 命令执行过程中会对表加读锁，对于MyISAM表会阻塞写操作，InnoDB表由于支持MVCC，读锁的影响较小，但是在高并发场景下还是建议在业务低峰期执行
- 频繁执行
AnalyzeTable可能会导致执行计划频繁变动，反而影响查询稳定性，建议在表数据变更量超过一定比例（比如变更超过30%数据）时再手动执行 - 如果开启了持久化统计信息，
AnalyzeTable的更新结果会持久化存储，重启mysql后不需要重新统计，非持久化统计信息重启后会丢失，需要重新执行分析命令
可以通过查询mysql.innodb_table_stats表查看表的统计信息是否更新成功，示例查询语句如下：
-- 查询指定表的统计信息，table_name替换为实际表名 SELECT * FROM mysql.innodb_table_stats WHERE table_name = '表名';
通过理解AnalyzeTable的执行原理，开发者可以更合理地使用该命令，在保障统计信息准确性的同时，尽量减少对业务的影响，提升mysql的查询性能。
mysqlAnalyzeTable优化器统计信息数据库优化修改时间：2026-07-22 17:39:24