MySQL的analyze操作是数据库维护中用于采集表统计信息的重要功能，统计信息会被查询优化器用来评估不同执行计划的成本，从而选择更优的查询路径。准确的统计信息能够避免优化器选择低效的索引或者全表扫描，提升整体查询效率。
analyze操作的核心作用
MySQL的查询优化器依赖表的统计信息来决定查询的执行方式，这些统计信息包括表的行数、索引的基数、索引的分布情况等。analyze操作的核心作用就是重新采集这些统计信息，更新到系统表中，让优化器能够基于最新的数据特征生成执行计划。如果统计信息过时，可能会出现明明有合适索引但优化器却选择全表扫描的情况，执行analyze后往往能解决这个问题。
手动执行analyze的方法
基础语法
手动执行analyze的语法非常简单，支持对单个表、多个表甚至整个数据库进行操作：
-- 分析单个表 ANALYZE TABLE user_table; -- 同时分析多个表 ANALYZE TABLE user_table, order_table, product_table; -- 分析整个数据库的所有表（需要借助存储过程或者脚本实现，MySQL没有内置单条语句支持）
执行结果说明
执行ANALYZE TABLE语句后，会返回一张结果表，包含以下字段：
| 字段名 | 说明 |
|---|---|
| Table | 被分析的表名 |
| Op | 操作类型，此处固定为analyze |
| Msg_type | 消息类型，包括status、error、info、warning |
| Msg_text | 具体的消息内容，比如执行成功会显示OK |
如果Msg_text显示OK，说明统计信息已经成功更新。如果出现错误，需要根据错误信息排查问题，比如表不存在、没有操作权限等。
不同存储引擎的差异
MySQL常用的存储引擎是InnoDB和MyISAM，两者执行analyze的逻辑有区别：
- InnoDB：analyze操作会读取表中一部分数据页来估算统计信息，不会锁表，对线上业务影响较小，统计信息是估算值，不是精确值。
- MyISAM：analyze操作会读取整个表的数据来生成精确的统计信息，执行期间会对表加读锁，可能会影响写入操作。
自动采集统计信息的机制
除了手动执行analyze，MySQL也有自动更新统计信息的机制，以InnoDB为例：
InnoDB会在表的数据发生较大变化的时候自动触发统计信息更新，默认的触发条件是表中超过10%的行被修改。可以通过以下参数调整自动采集的行为：
-- 查看自动更新统计信息的触发比例，默认是10，即10% SHOW VARIABLES LIKE 'innodb_stats_persistent_sample_pages'; -- 查看是否开启持久化统计信息，默认开启 SHOW VARIABLES LIKE 'innodb_stats_persistent'; -- 设置统计信息更新触发比例，比如设置为20，即20%的行被修改后自动更新 SET GLOBAL innodb_stats_persistent_sample_pages = 20;
如果开启了持久化统计信息，统计信息会保存在mysql.innodb_table_stats和mysql.innodb_index_stats系统表中，重启数据库后也不会丢失。如果关闭持久化，统计信息会保存在内存中，重启后需要重新采集。
执行analyze的注意事项
- 不要在业务高峰期对大表执行analyze操作，虽然InnoDB的analyze影响较小，但大表的采样过程还是会消耗一定的IO和CPU资源。
- analyze操作不会修改表的实际数据，只会更新统计信息，所以不会对数据一致性造成影响。
- 如果表的统计信息已经比较准确，不需要频繁执行analyze，避免不必要的资源消耗。
- 对于分区表，可以对单个分区执行analyze操作，语法为
ANALYZE TABLE 表名 PARTITION (分区名)。
验证统计信息是否更新
执行analyze之后，可以通过查询系统表来验证统计信息是否已经更新：
-- 查看表的行数等统计信息，n_diff_key_vals是索引的基数 SELECT * FROM mysql.innodb_table_stats WHERE table_name = 'user_table'; -- 查看索引的统计信息 SELECT * FROM mysql.innodb_index_stats WHERE table_name = 'user_table';
如果发现统计信息中的行数和实际行数差距较大，可以再次执行analyze操作重新采集。