在大型业务系统里，一条被验证过的高效SQL突然变慢，常常不是代码写了新逻辑，而是数据库优化器在重新编译时选了另一条执行路径。执行计划锁定就是人为干预这种自主选择，把已经确认性能达标的访问方式固定下来。它本质上是在优化器的"自由裁量权"上加上一道护栏，让关键语句始终走索引查找或既定的连接顺序，从而把响应时间波动压到最低。
为什么需要执行计划锁定来保障稳定性
优化器基于统计信息、参数值和代价模型来估算每种执行路径的成本。当夜间批量任务更新了统计信息，或者前端传入的查询参数从常见值变成极端值，原本走索引的执行计划可能被改写成全表扫描。这种不可预知的变更，在高并发核心链路上会瞬间放大成雪崩。执行计划锁定把"已经好的样子"存下来，下次编译直接复用，绕开重新决策的不确定性。
从故障归因角度看，没有锁定的环境里，性能劣化往往难以第一时间定位。运维人员看到慢查询，要翻执行计划缓存才能发现"昨天还是索引查找，今天变成哈希连接"。锁定之后，这条语句的计划身份是固定的，监控系统只要比对计划句柄就能确认是否发生了非预期变更。它把稳定性保障从被动救火变成主动防御。
也要注意，锁定并不等于永远不更新。表结构扩容、索引重建、数据分布彻底改变之后，旧计划可能不再是最优。因此稳定性策略里必须包含复审机制，比如每月抽取强制计划的使用频次与平均逻辑读，发现锁定的计划已明显落后于新统计信息时，在低风险窗口解除强制并观察优化器的新选择。
主流数据库的执行计划锁定实现方式
SQL Server提供了查询存储（Query Store）特性，可以捕获语句的历史计划，并通过sys.sp_query_store_force_plan存储过程把某个计划ID强制绑定到查询ID上。它的优势是图形化界面就能操作，且强制失败时会自动回退到正常编译，不会让语句直接报错。以下示例展示如何查看并强制一个计划：
-- 查找特定查询的候选计划
SELECT q.query_id, p.plan_id, p.query_plan_hash,
p.last_execution_time, p.avg_logical_reads
FROM sys.query_store_query AS q
JOIN sys.query_store_plan AS p
ON q.query_id = p.query_id
WHERE q.query_text_id IN (
SELECT query_text_id
FROM sys.query_store_query_text
WHERE query_sql_text LIKE N'SELECT * FROM Orders WHERE%'
);
-- 强制使用 plan_id = 12 的计划
EXEC sys.sp_query_store_force_plan
@query_id = 7,
@plan_id = 12;
Oracle数据库使用SQL计划基线（SQL Plan Baseline）来实现类似目标。基线允许优化器在确认新计划不差于已接受基线时才采用，这种"演进"机制比生硬冻结更灵活。DBA可以通过DBMS_SPM包从游标或历史捕获基线，再用ALTER语句启用固定。它的底层是把计划以hint集合形式存进数据字典，编译时优化器优先匹配这些hint。
MySQL自身没有原生的计划强制功能，但可以通过optimizer_switch关闭特定优化器行为，或者利用查询重写插件把语句改写成带FORCE INDEX的等价形式。这种方式侵入性较强，需要在应用层或代理层配合，但在无法升级企业版时也是一种务实的锁定思路。下表对比了三种数据库在锁定粒度与运维成本上的差异：
| 数据库 | 锁定机制 | 是否自动演进 | 运维复杂度 |
|---|---|---|---|
| SQL Server | 查询存储强制计划 | 否，需手动解除 | 低，内置界面 |
| Oracle | SQL计划基线 | 是，可验证后演进 | 中，需熟悉DBMS_SPM |
| MySQL | 改写或开关优化器 | 否 | 高，需改SQL或中间件 |
执行计划锁定的避坑与稳定性运维策略
最常见的误区是"把所有慢查询都锁定"。这会让优化器彻底失去自适应能力，当业务表从百万行涨到亿行、原有索引失效时，系统反而在锁定保护下持续使用劣质计划。正确做法是只对核心链路、计划易抖动、且已充分验证的语句做锁定，范围控制在总SQL量的百分之五以内较为稳妥。
另一个隐患来自参数嗅探。某些语句第一次编译用了极端参数，生成的计划被锁定后，正常参数也跟着走糟糕路径。此时应配合变量重编译或优化器提示，让锁定只约束结构不约束具体常量推断。例如在SQL Server可用OPTION (RECOMPILE)配合强制计划，既固定连接顺序又按实参优化局部扫描边界。
稳定性保障还要建立退出机制。建议设置强制计划的有效期标记，到期自动进入观察模式：解除强制但保留历史基线，若优化器新计划连续三天指标优于旧计划，则正式废弃旧锁定；若新计划更差，系统告警并重新强制。这样锁定策略就成了有生命的循环，而不是一次性胶水。配合变更评审，任何索引删除或统计信息大规模更新前，都要先扫描受影响强制计划清单，避免上游结构变了下游还在盲飞。