执行计划突变是优化器基于失真统计信息的诚实误判；主因是索引基数估算不准，源于采样页少（默认20页）与数据倾斜，需调高innodb_stats_persistent_sample_pages、关自动采样、建直方图，并在分页过深、函数条件、JOIN顺序异常时合理使用优化器提示。
执行计划突变不是“抽风”，是优化器基于统计信息做出的诚实误判。核心解法不是锁死计划，而是让统计信息更稳、让优化器选择更可预期。
为什么EXPLAIN结果会隔天就变
根本原因是 INFORMATION_SCHEMA.STATISTICS 里记录的索引基数（cardinality）不准，而 InnoDB 默认只随机采样 20 个索引页（由 innodb_stats_persistent_sample_pages 控制）。数据分布一旦倾斜（比如 status 字段 95% 是 'pending'），两次采样结果可能差几倍——优化器据此算出的代价就完全不同。
常见触发点：
- 日结/批量导入后行变更超 10%，自动触发
ANALYZE TABLE（由innodb_stats_auto_recalc控制） - 表上没主键或唯一索引，InnoDB 用隐藏的
ROW_ID当聚簇索引，统计信息更不可靠 - 使用
mysqldump --single-transaction导出时，若期间有 DML，可能导致采样页不一致
怎么让统计信息不再“漂”
目标不是消灭波动，而是收窄波动范围。关键参数要调：
- 把
innodb_stats_persistent_sample_pages从默认 20 提高到 100 或 200（MySQL 8.0+ 支持），采样页越多，基数估算越稳 - 关闭自动重采样：
SET GLOBAL innodb_stats_auto_recalc = OFF，改用定时任务在低峰期手动跑ANALYZE TABLE t1, t2 - 对高频查询的冷门值字段（如
status IN ('failed', 'cancelled')），用ANALYZE TABLE t1 UPDATE HISTOGRAM ON status建直方图（8.0+）
注意：ANALYZE TABLE 是轻量操作，但会加 MDL_SHARED_READ 锁，避免在大事务高峰期执行。
哪些场景必须加优化器提示
当统计信息再准也压不住业务逻辑的特殊性时，就得人工干预。以下情况直接上提示，别赌优化器：
- 分页深度过大（
LIMIT 100000, 20），优化器常误判为“扫完前 10 万行很快”，实际 I/O 爆炸 → 加/*+ USE_INDEX(t1, idx_created_at) */ - WHERE 条件含函数或表达式（
WHERE DATE(created_at) = '2024-01-01'），索引必然失效 → 改写为范围查询，并用/*+ FORCE_INDEX(t1, idx_created_at) */ - 多表 JOIN 时，优化器因小表数据量突增误选驱动表 → 用
/*+ STRAIGHT_JOIN */固定连接顺序
提示要写在 SQL 开头，且必须带空格和星号（/*+），否则 MySQL 当普通注释忽略。
为什么别碰“执行计划缓存”这类方案
MySQL 本身不提供执行计划持久化，所有所谓“固化计划”的第三方插件或 hack 方案，本质都是在绕过优化器做静态绑定。后果很现实：
- 数据量涨 10 倍后，原来最优的索引范围扫描变成最差的回表风暴
- 升级 MySQL 小版本后，优化器规则变动导致提示被无视或报错
- 同一 SQL 在不同字符集连接下（如 utf8mb3 vs utf8mb4），提示可能失效
真正该盯住的，是 information_schema.INNODB_TABLESTATS 里的 last_update 时间戳，以及每次慢查询发生时立刻抓取的 EXPLAIN FORMAT=JSON 输出——计划可以变，但变化必须可追溯、可解释。
