开启 innodb_stats_persistent 后统计信息不会自动刷新，仅在 analyze table、重启 mysql 或满足 innodb_stats_auto_recalc 阈值（10% 行变更）时更新，小表可能长期不更新，需手动干预。
innodb_stats_persistent 开启后，统计信息不会自动刷新？
默认开启 innodb_stats_persistent 后，MySQL 不再每次查询都重新采样，而是把统计信息存到 mysql.innodb_table_stats 和 mysql.innodb_index_stats 这两张系统表里。但这也意味着：**数据大量变更后，执行计划可能变差，而优化器却“浑然不觉”**。
常见错误现象：EXPLAIN 显示走了全表扫描，但实际只查几千行；SELECT COUNT(*) 突然变慢；某天加完索引后查询反而更慢。
- 触发更新的条件有限：只有执行
ANALYZE TABLE、重启 MySQL、或达到采样阈值（由innodb_stats_auto_recalc控制）才会更新 -
innodb_stats_auto_recalc = ON时，仅当表中 10% 行被修改才触发（这个比例不可调） - 小表（行数
innodb_stats_persistent_sample_pages × 20）可能永远不触发自动更新
什么时候该手动 ANALYZE TABLE？
不是所有 DML 都值得立刻分析，重点盯住三类场景：
- 大批量
INSERT/DELETE/UPDATE（比如凌晨跑完 ETL 后） - 新建或重建索引后（尤其
DROP INDEX + CREATE INDEX组合） - 发现某条查询执行计划突变，且
EXPLAIN中rows值明显偏离实际结果
注意：ANALYZE TABLE 是轻量操作，但会锁表（MDL），在高并发写入场景下建议避开业务高峰。对大表可加 INFORMATION_SCHEMA.INNODB_TABLESTATS 查看上次更新时间，避免盲目执行。
innodb_stats_persistent_sample_pages 影响精度和速度
这个参数决定采样页数，默认是 20。它不是“越大越好”，而是个平衡点：
- 设太小（如 1）→ 采样不足 → 统计偏差大 → 优化器选错索引
- 设太大（如 200）→ 分析耗时显著上升 →
ANALYZE TABLE可能卡几秒甚至分钟（尤其 SSD 性能一般时） - 对单表生效：可通过
ALTER TABLE t STATS_SAMPLE_PAGES=50单独调优，比全局改更安全
实测经验：普通 OLTP 表保持默认 20 足够；宽表（>50 列）、高频范围查询的表可提到 50–100；列极少但行极多的表（如日志归档）反而可降到 10。
如何确认当前统计是否“过期”？
别猜，直接查系统表和状态变量：
- 看最后更新时间：
SELECT * FROM mysql.innodb_table_stats WHERE database_name='db' AND table_name='t';关注last_update - 对比实际行数：
SELECT table_rows FROM information_schema.tables WHERE table_schema='db' AND table_name='t';—— 这个值不准，但和mysql.innodb_table_stats.n_rows差 3 倍以上就该警惕 - 检查是否被禁用：
SHOW VARIABLES LIKE 'innodb_stats_persistent';和SHOW VARIABLES LIKE 'innodb_stats_auto_recalc';
容易忽略的一点：如果表使用了 CREATE TABLE ... STATS_AUTO_RECALC=0，那即使全局开了 innodb_stats_auto_recalc，这张表也永远不会自动更新——这种设置常出现在归档表或只读报表库中，但容易被遗忘。
