执行计划突变是优化器基于失真统计信息的诚实误判主因是索引基数估算不准源于采样页少默认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 或 200MySQL 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哪些场景必须加优化器提示当统计信息再准也压不住业务逻辑的特殊性时就得人工干预。以下情况直接上提示别赌优化器分页深度过大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 FORMATJSON输出——计划可以变但变化必须可追溯、可解释。github.com/cainrodney3105/olbays/blob/main/153394458046.md