ANALYZE TABLE 会在表首次被打开、显式执行该命令、或 innodb_stats_auto_recalc=ON 且变更行数超预估行数10%并含二级索引时自动触发；它通过采样20个数据页估算统计信息，非全表扫描，结果存在误差。
什么时候 ANALYZE TABLE 会自动触发？
MySQL 不会在每次 INSERT/UPDATE 后自动更新索引统计信息，只有少数明确场景下才会触发：表首次被打开、执行 ANALYZE TABLE、或开启 innodb_stats_auto_recalc=ON 且表变更行数超 10%（默认阈值）且有二级索引时。注意：这个“10%”是基于 INFORMATION_SCHEMA.INNODB_TABLESTATS 中的预估行数，不是实时精确值。
常见误解是“只要数据变了，执行计划就立刻变”，其实不会。比如批量导入 5 万行后直接 EXPLAIN，优化器仍可能沿用旧统计信息，导致走错索引。
-
innodb_stats_auto_recalc默认为ON，但只对CREATE TABLE ... STATS_AUTO_RECALC=1创建的表生效；已有表需手动ALTER TABLE t STATS_AUTO_RECALC=1 - 临时表、内存表、分区表的子分区不参与自动统计更新
- 如果
innodb_stats_persistent=OFF（老版本默认），统计信息只存在内存中，重启后丢失，必须手动ANALYZE
ANALYZE TABLE 执行时会发生什么？
它不是“扫描全表”，而是采样估算：InnoDB 默认采样 20 个数据页（由 innodb_stats_sample_pages 控制），每页取部分记录构建列值分布和基数（cardinality）。这意味着结果本身就有误差，尤其当数据倾斜严重（如某字段 90% 是 'active'）时，cardinality 可能严重失真。
执行期间会加 MDL 共享锁（非阻塞 DML），但大表采样可能持续数秒——这不是 I/O 瓶颈，而是采样逻辑本身需要遍历 B+ 树叶子页链表。
- 采样页数可临时调高：
SET GLOBAL innodb_stats_sample_pages = 100，但仅对后续ANALYZE生效，且过高会延长执行时间 -
ANALYZE TABLE不阻塞SELECT/INSERT，但会短暂阻塞其他ANALYZE或ALTER - 对 MyISAM 表是直接计算精确值，行为完全不同，别混用
为什么 EXPLAIN 显示的 rows 和实际相差巨大？
因为 rows 来自统计信息里的 cardinality 估算，而该值依赖两个关键前提：数据均匀分布、采样足够代表整体。现实里这两点常不成立。例如一个时间戳字段，新数据集中在最近 1 小时，但采样页随机落在历史冷区，就会低估范围查询的匹配行数。
另一个典型坑是：使用了前缀索引（如 INDEX (name(10))），统计信息只基于前 10 字符计算 cardinality，但 WHERE name = 'JohnDoe123' 实际匹配靠的是完整值——此时优化器误判选择性，可能放弃索引。
- 检查当前统计是否陈旧：
SELECT * FROM INFORMATION_SCHEMA.STATISTICS WHERE TABLE_NAME = 't' AND TABLE_SCHEMA = 'db'，看INDEX_COMMENT是否含stats_cached - 强制刷新单个索引：
ANALYZE TABLE t UPDATE HISTOGRAM ON col1, col2（MySQL 8.0+），比全表ANALYZE更轻量 - 避免在
WHERE中对索引列用函数：WHERE YEAR(created_at) = 2024会让统计信息完全失效
生产环境怎么安全地更新统计信息？
不能靠“定时 ANALYZE TABLE”，因为大表可能卡住备份或慢查询日志归档。更稳妥的方式是结合数据变更特征做条件触发：比如 ETL 任务结束后、每日凌晨低峰期、或监控到某表 INFORMATION_SCHEMA.INNODB_TABLESTATS 的 MODIFIED_COUNTER 突增超过阈值时再执行。
还要注意权限：执行 ANALYZE TABLE 需要 PROCESS 权限（某些托管 MySQL 如 RDS 默认关闭），且对系统库表无效。
- 脚本化示例：
mysql -e "SELECT CONCAT('ANALYZE TABLE ', TABLE_SCHEMA, '.', TABLE_NAME, ';') FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'prod' AND TABLE_ROWS > 100000;" | mysql - 跳过临时表和视图：
AND TABLE_TYPE = 'BASE TABLE' - 如果用了
pt-online-schema-change，它默认会自动ANALYZE新表，无需额外操作
统计信息不是越新越好，频繁更新反而让执行计划抖动。关键是理解它怎么影响优化器决策，而不是把它当成必须“保持最新”的配置项。
