optimize for unknown 不等于固定执行计划，它仅让优化器忽略参数实际值、按列统计密度估算，仍生成并缓存计划，无法防止重编译，也不适用于dml子查询，且在sql server 2016+中可能被自适应查询处理绕过。
SQL Server 存储过程中用 OPTION (OPTIMIZE FOR UNKNOWN) 不能“固定”计划，它只是让优化器忽略本次参数值、按列统计密度估算——生成的仍是缓存计划，且可能不如局部变量稳定。
为什么 OPTIMIZE FOR UNKNOWN 不等于固定执行计划
这个提示不会锁定或导出计划，它只在编译时告诉优化器：“别看传进来的 @Param 值，按整列数据分布的平均选择率来算”。结果仍是标准缓存流程：生成一次、复用多次。如果列本身分布极不均匀（比如 95% 的值集中在 3 个状态码），这种“平均估算”会持续产生次优计划。
- 它无法防止后续因统计信息更新触发的自动重编译
- 不适用于
INSERT/UPDATE/DELETE语句的子查询中（语法报错） - 在 SQL Server 2016+ 中，它和自适应查询处理（Adaptive Query Processing）存在兼容性风险，某些场景下会被绕过
OPTIMIZE FOR (@Param = ...) 才是真·固定参数值编译
当你明确知道某个典型值（如高频、中位数、业务主路径值）能代表大多数调用，就用字面量强制锚定：
SELECT * FROM Orders WHERE Status = @Status OPTION (OPTIMIZE FOR (@Status = 'Shipped'));
这会让优化器始终以 'Shipped' 为依据生成计划，而非首次运行时的任意值。但注意：
- 必须确保该值在真实业务中确实具备代表性，否则会把“抖动”变成“全慢”
- 若
@Status是VARCHAR类型，字面量长度要匹配变量定义（如@Status VARCHAR(20)，就不能写OPTIMIZE FOR (@Status = 'Processing')—— 超长截断会引发隐式转换 - 不支持变量表达式，
OPTIMIZE FOR (@Status = @DefaultStatus)会直接报错
比 OPTIMIZE FOR 更稳的替代方案
真正想规避参数探测又不想每次重编译，优先考虑这些实操路径：
- 用局部变量屏蔽：
DECLARE @LocalStatus VARCHAR(20) = @Status;后续所有查询都用@LocalStatus—— 优化器失去具体值，退回到统计密度估算，稳定性高于UNKNOWN - 对关键语句加
OPTION (RECOMPILE)：适合低频调用或参数跨度极大（如分页OFFSET从 0 到 1000 万）的场景，编译开销远小于执行开销时才划算 - SQL Server 2016+ 可建计划指南（
sp_create_plan_guide）：把已验证高效的计划硬绑定到语句上，绕过所有运行时估算逻辑，但需手动维护、失效后无 fallback
最容易被忽略的是嵌套调用链中的穿透问题：A 过程传参给 B，B 用了 OPTIMIZE FOR UNKNOWN，但 A 是 EXEC B @X = UPPER(@Y) —— 此时 SQL Server 仍可能“嗅探”到 @Y 的原始值。真要稳，得在 B 开头就用局部变量接住，别依赖任何提示。
