innodb_stats_auto_recalc 默认开启但仅当数据变更超10%且行数≥25时触发；小表或低频更新表不生效，需结合ANALYZE TABLE手动优化，并注意MDL锁、权限及从库限制。
MySQL 8.0+ 的 innodb_stats_auto_recalc 怎么开才真正生效
自动更新统计信息不是“开了就完事”，关键看表是否满足触发条件。默认开启的 innodb_stats_auto_recalc 只在表数据变更量超过 10% 且行数 ≥ 25 才触发，小表或低频更新表基本不会动。
- 确认当前值：
SHOW VARIABLES LIKE 'innodb_stats_auto_recalc';（应为ON） - 强制对单表重算：
ANALYZE TABLE t1;（注意：会加 MDL 读锁，大表慎用） - 如果表长期不触发，别急着写定时任务——先检查
INFORMATION_SCHEMA.INNODB_TABLES里STATS_INITIALIZED是否为Done，否则连基础统计都没建好 - 该开关对临时表、分区表子分区无效，分区表需单独
ANALYZE TABLE t1 PARTITION(p1);
手动定时执行 ANALYZE TABLE 的安全写法
直接 crontab 调 mysql -e "ANALYZE TABLE..." 容易卡住连接或撞上锁，尤其在业务高峰。
- 优先用
mysqlcheck --analyze --databases db1 db2，它自带连接池和错误跳过逻辑 - 避免全库扫：
SELECT CONCAT('ANALYZE TABLE ', table_schema, '.', table_name, ';') FROM information_schema.tables WHERE engine='InnoDB' AND table_schema NOT IN ('mysql','information_schema','performance_schema','sys');生成语句后筛选大表/核心表 - 加超时控制：命令行用
timeout 300 mysql -u... -e "ANALYZE TABLE t1;"防止 hang 死 - 别在从库执行——
ANALYZE TABLE在从库不复制，但可能干扰 SQL 线程（尤其 GTID 模式下）
MySQL 5.7 及更早版本没有自动重算，只能靠外部调度
5.7 的 innodb_stats_auto_recalc 默认是 OFF，且即使打开，行为也不如 8.0 稳定，必须依赖外部定时器。
- 不要用
mysqldump那套脚本顺手加ANALYZE——dump 本身已锁表，再分析等于雪上加霜 - 推荐用
pt-online-schema-change --dry-run类工具间接触发（它内部会调ANALYZE），但仅限需要改表结构的场景 - 简单可靠的做法：crontab 每日凌晨跑一次轻量脚本，只分析近 7 天有 DML 的表（查
performance_schema.table_io_waits_summary_by_table或慢日志解析） - 注意 MySQL 用户权限：需
PROCESS+SELECToninformation_schema+ANALYZEon target tables
ANALYZE TABLE 执行时的锁表现和性能影响
很多人以为只是“读操作”，其实它会对表加短暂的元数据锁（MDL），且扫描过程消耗 I/O 和 CPU，尤其对大表。
- MyISAM 表：加表级读锁，期间不能写入
- InnoDB 表：只加 MDL 锁（非行锁），但会阻塞后续 DDL（如
ALTER TABLE），不影响 DML - 执行时间取决于
innodb_stats_persistent_sample_pages（默认 20），值越小越快但统计越粗糙；线上建议保持默认，除非明确知道采样偏差导致执行计划劣化 - 频繁执行没意义：两次
ANALYZE间隔小于数据变化量阈值，优化器仍用旧统计；反而增加系统抖动
实际用起来最麻烦的不是怎么设定时任务，而是判断“到底要不要分析”——统计信息滞后是否真影响了某条慢查询的执行计划。得先看 EXPLAIN FORMAT=JSON 里的 rows_examined_per_scan 和实际扫描行数是否差一个数量级，再动手。
