ANALYZE更新索引统计

在数据库管理领域，统计信息是优化器生成执行计划的“眼睛”。当你在MySQL命令行敲下ANALYZE TABLE的那一刻，背后触发的是一个精密的索引统计更新流程。很多人只知道执行这个命令能让慢查询变快，却不清楚它到底更新了什么、怎么更新的、以及为什么有时候更新完反而性能更差。这篇文章直接拆解ANALYZE更新索引统计的底层机制，给出生产环境的最佳实践。

执行ANALYZE TABLE时，MySQL会重新计算索引的基数、列的离散度分布以及键值的分布范围。具体来说，它更新的是mysql.innodb_index_stats和mysql.innodb_table_stats这两张系统表里的数据。对于InnoDB引擎，统计信息包括索引中不同值的数量、索引页的数量、B+树的层数以及采样过程中发现的数据分布特征。MyISAM引擎则通过key_distribution和table_statistics来存储这些信息。

很多人误以为ANALYZE只是简单更新基数，实际上它还会影响优化器对范围扫描成本的计算。当索引统计信息过期后，优化器可能错误估计需要扫描的行数，导致本该用索引的查询走了全表扫描。ANALYZE的核心价值就是纠正这种信息不对称，让优化器做出更准确的成本估算。

理解ANALYZE的行为，必须先搞清楚innodb_stats_persistent这个参数。当设置为ON时，统计信息会持久化到磁盘，MySQL重启后依然有效。当设置为OFF时，统计信息只存在内存中，每次重启都会触发自动重新计算。生产环境强烈建议开启持久化模式，避免重启后统计信息丢失导致的执行计划突变。

在持久化模式下，ANALYZE的执行过程是这样的：InnoDB会随机采样一定数量的索引页，通过扫描这些页来估算整个索引的基数。采样页的数量由innodb_stats_persistent_sample_pages控制，默认值是20。这个参数直接影响统计信息的准确度。采样页太少，基数估算可能偏差很大；采样页太多，ANALYZE本身会消耗大量IO资源。对于大表，适当增加这个值到100甚至200，可以显著提升统计信息的准确性。

InnoDB采用了一种叫做“随机跳水”的采样策略。它会随机选择N个索引页作为采样点，然后从每个采样点开始扫描一定数量的记录，通过分析这些记录中键值的变化来估算整个索引的不同值数量。这个算法有个关键特性：它不是均匀采样整个索引树，而是偏向于采样叶子节点。对于B+树索引来说，叶子节点包含了全部数据，这种采样策略能较好地反映真实的数据分布。

但问题在于，当数据分布极度不均匀时，随机采样可能恰好错过那些数据密集的区域。比如一个用户表的城市字段，如果90%的用户都在北京，而采样页恰好没覆盖到北京的记录，那么基数估算就会严重偏高。这就是为什么有时候ANALYZE更新后，优化器反而选择了更差的执行计划。解决这个问题的方法是增加采样页数量，或者使用innodb_stats_method参数调整NULL值的处理方式。

这个参数决定了MySQL如何统计包含NULL值的索引列。设置为nulls_equal时，所有NULL值被视为相同，这会降低索引的基数估算。设置为nulls_unequal时，每个NULL值被视为不同，基数估算会偏高。设置为nulls_ignored时，NULL值直接被忽略不计。对于大多数业务场景，nulls_equal是最合理的选择，因为它更接近实际查询中NULL值的比较逻辑。但如果你经常执行IS NULL或者IS NOT NULL的查询，可能需要根据实际情况调整这个参数。

不要盲目定时执行ANALYZE。在以下场景手动触发是最有价值的：大批量数据导入或删除后，表的数据量变化超过10%时；新建索引后，需要让优化器立即认识这个新索引；执行计划突然变差，怀疑统计信息过期时；从备份恢复数据后，统计信息可能不准确。执行时要注意，ANALYZE TABLE会申请MDL读锁，虽然不会阻塞读写操作，但在高并发场景下仍可能造成短暂的性能抖动。

对于超大表，直接执行ANALYZE可能需要几分钟甚至更长时间。这时可以考虑只更新特定索引的统计信息，虽然MySQL标准语法不支持指定索引，但可以通过先删除统计信息再重新收集的方式来间接实现。或者利用pt-query-digest这类工具分析慢查询，只对问题查询涉及的索引进行针对性的统计更新。

InnoDB有一个后台线程负责自动更新统计信息。当表中修改的行数超过总行数的10%时，就会触发自动ANALYZE。这个阈值由innodb_stats_auto_recalc参数控制。但这里有个陷阱：自动更新使用的是默认的采样页数量，可能不够精确。而且在高并发写入的场景下，频繁触发自动更新会消耗大量IO。对于写入密集的表，建议关闭自动更新，改为在业务低峰期手动执行。

另一个容易被忽略的细节是，information_schema中的某些查询也会触发统计信息更新。当你查询TABLES或STATISTICS表时，如果innodb_stats_on_metadata参数开启，MySQL会实时计算统计信息。这个参数在生产环境建议关闭，避免元数据查询导致意外的性能开销。

当优化器选择了错误的索引时，第一步就是检查统计信息是否准确。通过SHOW INDEX FROM table_name可以看到索引的基数，把这个值和实际SELECT COUNT(DISTINCT column)的结果对比，如果偏差超过30%，就说明统计信息需要更新了。更深入的排查可以查询mysql.innodb_index_stats表，查看last_update字段确认统计信息的更新时间。

有一个经典的案例：某电商系统的订单表按创建时间范围查询时突然变慢。排查发现，由于前一天进行了大批量的历史数据归档，删除了大量旧数据，但统计信息没有及时更新。优化器仍然认为全表扫描的成本更低，因为基数估算显示数据量还是归档前的规模。执行ANALYZE后，查询立即恢复了正常。这个案例说明，在数据量发生剧烈变化后，必须第一时间更新统计信息。

从MySQL 8.0开始，引入了直方图统计功能，这是对传统索引统计的有力补充。索引统计只能反映索引列的整体基数，而直方图可以描述列内部的数据分布情况。比如一个状态字段只有0、1、2三个值，索引统计只能告诉你基数约为3，但直方图可以告诉你有多少行是0、多少行是1。对于数据倾斜严重的列，创建直方图能让优化器做出更精准的行数估算。

ANALYZE TABLE命令不会自动更新直方图，直方图需要通过ANALYZE TABLE ... UPDATE HISTOGRAM语法单独管理。在实际使用中，建议对经常出现在WHERE条件中且数据分布不均匀的列创建直方图，并定期更新。直方图的更新频率可以低于索引统计，因为数据分布模式通常不会频繁改变。

InnoDB的ANALYZE是随机采样，而MyISAM则是全索引扫描，因此MyISAM的统计信息更准确但执行更慢。Memory引擎使用哈希索引，ANALYZE的行为又有所不同，它主要更新的是键值的分布信息。对于使用分区表的情况，ANALYZE TABLE会同时更新所有分区的统计信息，但每个分区是独立采样的，这可能导致分区裁剪时优化器的估算出现偏差。

一个常见的误区是认为ANALYZE会重建索引或者整理碎片。实际上它只更新统计信息，不涉及任何索引结构的修改。如果需要重建索引以提升性能，应该使用OPTIMIZE TABLE或者ALTER TABLE ... ENGINE=InnoDB。把这两个操作混淆，可能导致做了无用功还影响业务。

首先，在执行前通过pt-query-digest或慢查询日志分析当前的问题查询，确认确实是指统计信息导致的。其次，选择业务低峰期执行，对于超大表可以分批处理。执行时建议开启会话级别的innodb_stats_persistent_sample_pages，临时提高采样精度。执行后立即观察慢查询的变化，如果性能反而下降，说明采样精度可能不够，需要增加采样页数量后重新执行。

最后，建立统计信息的监控体系。定期检查mysql.innodb_index_stats表中统计信息的更新时间，对于长时间未更新的表设置告警。同时监控执行计划突变的查询，这类查询往往是指统计信息问题的第一信号。把ANALYZE从一个应急操作变成可预测的维护流程，才是成熟的数据库运维之道。