EXPLAIN执行计划未变是因为MySQL优化器依赖的统计信息非实时更新，需手动执行ANALYZE TABLE刷新索引采样数据，否则可能导致选错索引或全表扫描。
为什么 EXPLAIN 显示的执行计划没变，即使表数据已大幅变动
MySQL 的查询优化器依赖表的统计信息（比如索引基数、行数估算）来生成执行计划，这些信息不是实时更新的。你改了大量数据、加了新索引、甚至 DELETE 掉 90% 行，EXPLAIN 还可能沿用旧的统计，导致选错索引或走全表扫描。
根本原因在于：InnoDB 默认只在特定触发条件下自动采样更新统计信息（如表变更量超 1/16 或首次打开表），且采样本身有随机性和误差；MyISAM 更被动，基本靠手动干预。
- 常见错误现象：
EXPLAIN显示用了低效索引，但FORCE INDEX强制另一个索引后查询快几倍 - 使用场景：批量导入/删除后、上线新索引后、慢查询反复出现且
WHERE条件明显能走索引却没走 - 性能影响：统计过时 → 优化器误判 → 执行计划劣化 → 查询响应时间陡增，尤其在大表上更明显
ANALYZE TABLE 是什么，它到底干了啥
ANALYZE TABLE 不是“刷新缓存”或“重建执行计划”，而是让 MySQL 重新采样索引页，更新 STATS_INITIALIZED、INDEX_LENGTH、AVG_ROW_LENGTH 等元数据，存在 mysql.innodb_table_stats 和 mysql.innodb_index_stats（InnoDB）或 information_schema.TABLES（MyISAM）中。后续 EXPLAIN 和优化器才可能用上新数据。
- 它不锁表（InnoDB 下是轻量级只读锁），但会短暂阻塞 DDL；MyISAM 下会加读锁
- 对大表耗时明显：默认采样约 10–20 个索引页，但若
innodb_stats_persistent = OFF，重启后统计丢失 - 不是万能的：如果表极度倾斜（如某值占 95% 行），采样仍可能低估选择性，这时需结合直方图（MySQL 8.0+）
执行 ANALYZE TABLE 的实操要点和坑
直接执行 ANALYZE TABLE t1 太粗糙，容易白忙活。关键要看存储引擎和持久化配置。
- 先确认是否启用持久化统计：
SELECT @@innodb_stats_persistent;，为ON才建议长期用ANALYZE TABLE - 对单表执行：
ANALYZE TABLE t1;，成功返回status: OK；失败常见报错：ERROR 1036 (HY000): Table 't1' is read only（检查read_only或从库权限） - 批量处理多个表：用脚本生成语句，避免手动敲，例如：
SELECT CONCAT('ANALYZE TABLE ', table_name, ';') FROM information_schema.tables WHERE table_schema = 'db1' AND table_rows > 10000; - 容易踩的坑：在从库执行会报错（除非关了
read_only）；高并发写入时执行可能引发短暂延迟；ANALYZE TABLE不会更新列级统计（如 NULL 比例），这部分靠采样估算
比 ANALYZE TABLE 更稳的替代方案
如果发现 ANALYZE TABLE 后执行计划还是不对，别硬刷，优先查根因。
- 检查是否被
optimizer_switch关键项禁用：运行SELECT @@optimizer_switch;，确认use_index_extensions=on、condition_fanout_filter=on等未被关掉 - 强制更新统计精度（MySQL 8.0+）：
ANALYZE TABLE t1 UPDATE HISTOGRAM ON col1, col2;，适合分布不均的字段 - 临时绕过统计误导：
SELECT /*+ USE_INDEX(t1, idx_col) */ * FROM t1 WHERE ...，仅用于紧急定位，不可长期依赖 - 真正复杂的情况：统计本身没问题，但优化器成本模型算错了（比如磁盘 IO 成本 vs 内存计算成本），这时候就得看
optimizer_trace输出，而不是反复ANALYZE
统计信息只是优化器的“参考地图”，不是“导航指令”。地图不准要更新，但要是方向感本身有问题，光换地图没用。
