mysql不支持oracle式的sql plan baselines，开源版需通过query_rewrite插件+hint组合模拟，且固定计划可能因数据倾斜、隐式转换等引发更大性能风险。
为什么 SQL Plan Baselines 是当前最稳妥的固定方式
MySQL 本身不支持 SQL Plan Baselines —— 这是 Oracle 的机制。如果你在 MySQL 环境下搜到“用 Baseline 固定执行计划”，基本是混淆了数据库厂商。真正能用的，是 optimizer_switch 控制开关、USE INDEX/FORCE INDEX 提示，或升级到 MySQL 8.0.31+ 后有限支持的 SQL Plan Management (SPM)（仅限企业版，且功能远弱于 Oracle）。开源版 MySQL 没有 Baseline 存储、演进、自动捕获这些能力。
MySQL 8.0 开源版里怎么模拟 Baseline 效果
靠组合使用 query_rewrite 插件 + hint + 手动绑定执行路径。核心思路不是“锁计划”，而是“让优化器只看到你想要的那条路”。
-
query_rewrite插件必须启用：INSTALL PLUGIN query_rewrite SONAME 'query_rewrite.so'，并确认query_rewrite_enabled=ON - 插入重写规则时，
pattern必须完全匹配原始 SQL（包括空格、换行、大小写），否则不生效；建议先用EXPLAIN FORMAT=TREE确认坏计划下的真实语句结构 - 重写后的语句里加
/*+ USE_INDEX(t1 idx_a_b) */这类 optimizer hint，比USE INDEX语法更稳定（后者在子查询或 JOIN 中容易失效） - 不要依赖
sql_mode='STRICT_TRANS_TABLES'来规避隐式转换导致的索引失效——它不改变执行计划选择逻辑
哪些场景下强行固定计划反而更糟
固定计划本质是用人工判断覆盖优化器成本估算，一旦数据分布或统计信息变化，可能从“快变慢”直接跳到“查不出结果”。典型危险信号：
- 表里
WHERE字段的值分布严重倾斜（比如status IN ('pending', 'done')中 99% 是done），而你锁的是走status索引的计划 - 关联字段存在隐式类型转换，例如
JOIN ON t1.id = t2.id_str（id是INT，id_str是VARCHAR），此时即使加FORCE INDEX，也可能因转换导致全表扫描 - 执行计划里出现
Using temporary; Using filesort，说明排序/分组已脱离索引能力——硬锁索引无法解决这类结构性瓶颈
比“固定计划”更值得优先做的三件事
频繁变更执行计划，大概率不是优化器坏了，而是底层条件松动了。先检查这些：
- 统计信息是否过期？
ANALYZE TABLE t1比任何 hint 都管用，尤其在大表批量导入后 - 是否存在未提交事务长期持有 MDL 锁？用
SELECT * FROM performance_schema.metadata_locks查看阻塞链，会干扰优化器对表结构的判断 - 是否在连接串里动态设置了
optimizer_switch（如关闭index_merge）？这种会话级配置比全局设置更难追踪，也更容易造成计划漂移
真要锁计划，别碰 Baseline 这个伪概念；盯住统计信息、锁状态、连接配置这三处，比写十条 hint 更接近问题根子。
