参数嗅探（Parameter Sniffing）这个问题，我估计每个做SQL Server开发和运维的人都被它坑过。同一个存储过程，上午跑得飞快，下午突然慢得吓人；换个参数值，执行时间从毫秒变成分钟；更诡异的是，手动清掉计划缓存，一切又恢复正常了。如果你也遇到过这种情况，那今天这篇内容就是为你准备的。
之前系列文章把NOLOCK、INDEX、FORCESEEK这类表提示和部分查询提示讲了一遍，今天继续聊几个直接干预“查询计划选择”的常用Hint：OPTIMIZE FOR、RECOMPILE、FORCESCAN、FORCE ORDER。这几个都作用于优化器的决策逻辑，用好了能精准解决参数嗅探和计划不良问题，用错了就是给自己挖坑。这篇文章适合DBA、后端开发和所有需要亲手调SQL Server性能的同行阅读，不管是2019、2022还是更早的版本，核心行为基本一致。
1. 参数嗅探与 OPTIMIZE FOR：先定位问题再动手
1.1 一个能复现的实例：状态字段的经典场景
先说一个我经常拿来举例子的场景。假设有一张订单表，目前有1000万行数据：
CREATE TABLE dbo.orders ( order_id INT IDENTITY(1,1) PRIMARY KEY, customer_id INT NOT NULL, status TINYINT NOT NULL, -- 1: Pending, 2: Completed, 3: Cancelled order_date DATETIME NOT NULL, total_amount DECIMAL(10,2) NOT NULL ); CREATE INDEX ix_orders_customer ON dbo.orders(customer_id); CREATE INDEX ix_orders_status ON dbo.orders(status);这张表的数据分布很极端：999万行是已完成（status=2），只有5000行是待处理（status=1），还有5000行是已取消（status=3）。然后我们写一个最普通的查询存储过程：
CREATE PROC dbo.GetOrdersByStatus @status TINYINT AS SELECT order_id, customer_id, order_date FROM dbo.orders WHERE status = @status ORDER BY order_date DESC;第一次执行时传入@status = 1，优化器一看返回行数少，走ix_orders_status的索引查找，配合键查找，逻辑读只有几千次，执行计划很漂亮。第二次执行传入@status = 2，结果复用了刚才那个计划，等于对999万行匹配数据逐行做键查找，逻辑读飙升到几十万次，查询直接慢了几十倍。这就是参数嗅探最典型的症状：计划本身没错，错在“用一个极少数场景的计划去服务另一个完全不同的场景”。
这里要强调一点，很多人遇到这种问题第一反应是“把索引删了”或者“加 WITH (NOLOCK)”，这完全是跑偏了。正确的第一步是定位计划到底在哪里产生了误判。你可以在SSMS里用“包含实际执行计划”跑两次不同参数的查询，重点看扫描还是查找、键查找次数、以及估算行数和实际行数的偏差。你会发现，问题往往出在基数估算（Cardinality Estimation）严重偏离实际，而不是索引本身不能用。
1.2 OPTIMIZE FOR 的语法、位置与两个容易被忽略的限制
针对上面的情况，OPTIMIZE FOR是一个立竿见影的方案。它的作用很好理解：告诉优化器，在编译计划时，把某个参数当作你指定的值去估算，但运行时用的仍然是实际传入的值。语法长这样：
CREATE PROC dbo.GetOrdersByStatus @status TINYINT AS SELECT order_id, customer_id, order_date FROM dbo.orders WHERE status = @status ORDER BY order_date DESC OPTION (OPTIMIZE FOR (@status = 2));这么写的意思是：每次编译或重编译时，优化器都把@status当作2来估算行数，于是会选择一个更适合大范围数据的执行计划，比如直接做聚集索引扫描。无论你实际传1、2还是3，执行时都还是传什么用什么，但底层计划是针对“大结果集”设计过的。这样做的效果是：最坏的情况可控了，所有参数都走同一个稳定计划，不会再出现“某个参数突然慢成狗”的极端情况。
不过用的时候有两个限制必须记住。第一，OPTION子句必须放在语句最后，很多人写存储过程时习惯在查询后面直接加分号或继续写下一段逻辑，结果Hint没生效。第二，OPTIMIZE FOR对IN (@param)这种写法不生效。比如WHERE status IN (@s1, @s2)，SQL Server会直接忽略你的Hint，因为优化器无法把一个列表参数映射到单个估算值上。这种场景要么改成动态SQL，要么直接用RECOMPILE。
另外还有一个开发小伙伴很容易踩的坑：OPTIMIZE FOR里指定的值不要求是真实存在的数据。比如OPTION (OPTIMIZE FOR (@status = 5))，哪怕表里根本没有status=5，编译时它也只会拿这个值去做基数估算，不会真的过滤数据。所以有些人喜欢用一个大范围值来“骗”优化器走向扫描路径，这种做法在特定场景下是有效的，但我不建议滥用，因为一旦数据量级发生变化，这种投机取巧就会反噬。
2. OPTIMIZE FOR UNKNOWN 与 RECOMPILE：两条不同的路
2.1 OPTIMIZE FOR UNKNOWN：用“平均估算”换稳定性
如果你不想硬编码一个值，又希望计划稳定，可以试试OPTIMIZE FOR UNKNOWN：
OPTION (OPTIMIZE FOR (@status UNKNOWN))UNKNOWN 的含义是让优化器放弃使用“嗅探到的实际参数值”，改用统计信息里的密度估算（density），也就是按“这些数据的平均值”来做基数估算。可以把它理解为“平均化”的中庸计划：不偏向任何极端参数，整体方差小，对多数参数都能接受，但也不太可能对某个特定参数做到最优。
这个选择适合什么场景？数据分布相对均匀、没有明显热点值的查询。比如一个字段取值是性别、省份、月份这种，每个值的行数差距不大，用UNKNOWN往往能得到一个长期稳定的计划。反过来，如果数据分布严重倾斜，比如90%的数据都集中在某一个值上，UNKNOWN估算出来的“平均值”就会离真实分布很远，选出来的计划可能对谁都好不到哪去。
有一点要注意：OPTIMIZE FOR UNKNOWN并不是“禁用参数嗅探”。参数嗅探发生在编译/重编译时，UNKNOWN只是改变了估值方式，没有改变“计划会被缓存并被复用”的事实。如果你想真正绕开缓存，得用OPTION (RECOMPILE)，这两者解决的问题层次不一样。
2.2 RECOMPILE：放弃计划缓存，换取每次最优
RECOMPILE的思路完全不同：每次执行都重新编译一次，每次都基于当前实际传入的参数、当前最新的统计信息、当前数据分布生成全新计划。语法可以在查询级用：
SELECT order_id, customer_id, order_date FROM dbo.orders WHERE status = @status ORDER BY order_date DESC OPTION (RECOMPILE);也可以在存储过程定义级别直接声明：
CREATE PROC dbo.GetOrdersByStatus @status TINYINT WITH RECOMPILE AS SELECT order_id, customer_id, order_date FROM dbo.orders WHERE status = @status ORDER BY order_date DESC;两者区别在于粒度：查询级只对该语句生效，存储过程级会让里面所有语句都被强制重编译。我一般优先用查询级，因为存储过程里往往只有一两条语句是问题语句，没必要为整个过程付出额外编译成本。
哪个场景应该用 RECOMPILE？我的经验是满足这几个条件之一就可以考虑：数据倾斜非常严重，每次参数值对应的结果集大小天差地别；查询执行频率低，比如报表、月末统计、每日跑批，编译开销摊薄后可以忽略；查询条件非常多、参数组合空间巨大，比如有8个可选筛选条件，优化器基本没有可能缓存到“合适”的计划。这几个场景下，RECOMPILE牺牲一点CPU换执行时间，完全划算。
但反过来，高频短查询千万别乱加。想象一个每秒执行几十次的OLTP小查询，本来计划缓存能省掉编译成本，你偏要让它每次都重编译，CPU直接被拉高一大截。我见过有同事为了修一个偶发慢查询，给一个高并发接口的SQL加了RECOMPILE，结果慢查询是没了，整体吞吐掉了20%，这就是典型的因小失大。
2.3 三种常用方案的选择清单
在实际调优时，我经常在 OPTIMIZE FOR 指定值、OPTIMIZE FOR UNKNOWN、RECOMPILE 三者之间权衡。下面这张表是我自己总结的，可以直接收藏：
| 方案 | 原理 | 最适合场景 | 最怕场景 | 主要代价 |
|---|---|---|---|---|
| OPTIMIZE FOR 指定值 | 编译时用指定值估算，运行时用实际值 | 业务能确定一个“代表多数情况”的值 | 热点值不固定，无法选出代表值 | 对偏离指定值的极端参数计划不佳 |
| OPTIMIZE FOR UNKNOWN | 用密度估算，做平均化计划 | 数据分布均匀，追求稳定 | 数据严重倾斜，平均值无意义 | 对所有参数都不是绝对最优 |
| RECOMPILE | 每次重新编译，每次都用实际参数 | 低频、参数组合多、数据倾斜大 | 高频短查询 | 增加编译CPU，无法复用计划缓存 |
3. FORCESCAN 与 FORCE ORDER：手动干预访问路径
3.1 FORCESCAN 强制扫描：什么时候划算
FORCESCAN属于表提示，作用很直白：强制优化器对指定表执行扫描，忽略它原本想走的索引查找路径。语法是：
SELECT order_id, customer_id, order_date FROM dbo.orders WITH (FORCESCAN) WHERE customer_id = @customer_id;看到这里你应该会问：优化器正常判断都不会蠢到用扫描吧？其实不然。我遇到过一个真实案例：一张客户维度表，数据量800万行，在某次批量更新后统计信息还没来得及更新，查询一个在业务上只占5%的客户ID时，优化器因为旧统计信息误判返回50%的数据，于是选择了聚集索引扫描。扫描本身不慢，但后续报表流程里这个查询要执行几百次，每次都在一张大表上全扫，整体跑批时间从40分钟涨到了3小时。这时候用FORCESCAN反而也是一种选择——因为问题的根源不是“扫描太慢”，而是优化器基于错误信息选择了更慢的查找路径。
另外一个常见场景是表很小但索引很多。比如一张配置表只有1000行，上面建了四五个索引，优化器有时候会因为成本计算误差选择非聚集索引查找，而实际扫描整表只要几十个逻辑读。这种情况下FORCESCAN能直接把计划按在正确的路径上。
但要特别注意，FORCESCAN和FORCESEEK是互斥的，对同一个表不能同时指定，否则直接报错。而且从2008R2 SP1开始才支持这个Hint，如果你还在运维老版本的实例，得确认一下兼容性。真正使用前，我建议先手工把两种路径的SET STATISTICS IO, TIME跑一遍，证明扫描确实更快再上Hint，别凭感觉硬扫。
3.2 FORCE ORDER：连接顺序也能手动指定
FORCE ORDER是一个查询提示，作用是让优化器严格按照FROM子句里表出现的顺序去执行连接，不再自行重新排列连接顺序。看一个例子：
SELECT c.customer_name, o.order_id, i.product_name FROM dbo.customers c INNER JOIN dbo.orders o ON c.customer_id = o.customer_id INNER JOIN dbo.order_items i ON o.order_id = i.order_id OPTION (FORCE ORDER);加了FORCE ORDER之后，SQL Server会先加载customers，再连接orders，最后连接order_items，表与表之间的连接顺序被锁死。默认情况下，优化器会枚举各种可能的连接顺序（左深树结构），选择估算代价最低的那种；FORCE ORDER相当于直接把这个搜索过程跳过，按你写的顺序来。
这个Hint的价值在于：当优化器的基数估算明显失真，导致它选择了一个糟糕的连接顺序，而你通过多次实测确认某种固定顺序更好时，可以直接“拍板”。比如A表1000行、B表100万行、C表1亿行，你明确知道必须先从小表开始驱动，但优化器因为统计信息过期选了从C表驱动，那就是灾难。
不过这里我要泼一盆冷水：FORCE ORDER 绝对不是我推荐的常规手段，而是最后手段。原因很简单，一旦锁死顺序，后续数据量增长、索引变更、统计信息更新，你的“心智模型”可能完全过时。而优化器是动态的，只要估价正确，它通常会比你更聪明。只有当你反复确认某种顺序确实最优，而且未来数据增长模式可控时，才值得用。
3.3 干预型Hint为什么是“最后手段”
把FORCESCAN和FORCE ORDER放在最后讲，不是因为他们不重要，恰恰因为他们太“暴力”。这一类直接干预执行路径的Hint，本质上是在替代优化器的决策。而优化器的决策建立在统计信息、直方图、索引结构等大量信息之上，你用一个写死的规则替代它，等于把它变成了静态脚本。
我见过最痛苦的案例，是有人在生产环境给一个核心查询同时加了FORCE ORDER、HASH JOIN和FORCESCAN，最初数据量200万时性能飞起。半年后数据涨到2000万，所有条件都变了，但那个计划还被钉死在数据库里，每个晚上跑批都超时。后来排查了半天才发现是这个“三合一”Hint在作祟。所以我的经验是：这类干预型Hint一定要在注释里写清楚“为什么加、谁加的、什么日期、预判什么时候可以去掉”，每季度审视一次，数据量出现数量级变化时重点复查。
4. Hint组合、优先级与验证方法
4.1 多个Hint同时指定的组合规则
查询提示可以同时指定多个，用逗号分隔，比如：
SELECT order_id, customer_id, order_date FROM dbo.orders WITH (FORCESCAN) WHERE status = @status ORDER BY order_date DESC OPTION (RECOMPILE, OPTIMIZE FOR (@status = 2));这段SQL同时用了表提示FORCESCAN和查询提示RECOMPILE、OPTIMIZE FOR，逻辑上是允许的。但组合时要多留个心眼，不是所有Hint都能和平共处。比如前面说过的FORCESEEK和FORCESCAN不能同时对一张表指定；FAST n和OPTIMIZE FOR UNKNOWN同时出现时，优化器的处理优先级也容易出现意外。
还有一个容易踩的坑是：同时指定了有冲突语义的Hint后，SQL Server 可能会直接忽略其中一个，或者整个语句报编译错误，但不会给你明确的警告。你可以用计划属性里的“Statement”和“Set Options”字段去核对到底哪个生效了。我的建议是，除非实在没办法，否则不要让一个查询同时挂着超过两个干预型Hint。每多一个Hint，优化器的搜索空间就被压缩一圈，任何一个假设出错，整体计划就会迅速劣化。
4.2 从执行计划验证Hint是否真正生效
加完Hint后，不能看一眼执行计划形状变了就以为成功，必须验证到具体细节。我最常用的验证手段有两个。
第一个是查看执行计划属性。在SSMS里执行完查询后，右键执行计划的最外层，选择“属性”，在“语句”区域能看到编译时优化器实际使用的参数值；在“参数列表”里能看到每个参数的Value字段，如果你设置了OPTIMIZE FOR (@status = 2)，这个值会显示为2，而不是实际传入的值。如果显示的是Unavailable或NULL，说明Hint没被应用。
第二个是从缓存里看计划，适合排查线上问题：
SELECT qs.execution_count, qs.total_logical_reads / qs.execution_count AS avg_logical_reads, qs.total_elapsed_time / qs.execution_count AS avg_elapsed_us, qp.query_plan, qt.text FROM sys.dm_exec_query_stats qs CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) qp CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) qt WHERE qt.text LIKE '%GetOrdersByStatus%' ORDER BY avg_logical_reads DESC;这个方法能看出同一段SQL在缓存里到底有几种计划、各执行了多少次、平均逻辑读多少。如果你加了RECOMPILE，那缓存里的execution_count通常会很低，因为计划每次执行完可能就被淘汰了。
4.3 加Hint之前的三个自检问题
在动手写任何Hint之前，我建议先自查三个问题，顺序不能乱：
第一，统计信息是最新的吗？很多“参数嗅探问题”根子上是统计信息过期。先执行UPDATE STATISTICS dbo.orders WITH FULLSCAN，再看看问题是否消失。据统计，我接手过的性能问题里，有三成在更新统计信息后直接自愈，根本不需要加Hint。
第二，索引设计合理吗？比如WHERE status = @status这种查询，如果建了(status, order_date DESC) INCLUDE(order_id, customer_id)的覆盖索引，可能所有问题直接消失，根本不用去管参数嗅探。Hint是在查询和索引设计都到位之后才考虑的事。
第三，这个Hint是短期救济还是长期方案？如果你经常写注释“临时解决，待优化”，那就要在代码评审时专门给这些Hint设一个复查日期。无主Hint和僵尸索引一样，都是生产环境的隐性炸弹。
5. 常见问题与排查技巧实录
5.1 参数嗅探问题的排查套路
每次有人跟我反馈“存储过程间歇性变慢”，我基本都按下面这个流程走，效率很高：
先抓取不同参数下的实际执行计划对比。最容易漏掉的是只看了“慢的时候”的计划，没和“快的时候”对比，结果找不准差异。对比时重点看三处：操作符类型（Scan还是Seek）、估算行数vs实际行数、关键表的访问顺序。差异越大，越可能是参数嗅探。
再看计划缓存的命中情况。用上一节的那段DMV查询，看目标存储过程是否只有一个计划在反复复用，并且该计划的估算行数和实际执行行数严重不符。如果是，基本可以锁定问题。
最后做隔离验证。可以在开发环境执行DBCC FREEPROCCACHE (plan_handle)清掉某个特定计划，再重新执行慢参数，观察是否恢复。注意生产环境不要直接清整个缓存，否则所有查询都要重新编译。
5.2 Hint没生效的常见原因速查
有些场景下Hint加了跟没加一样，很多新人卡在这里。我整理一下最常见的几个原因：
| 原因 | 说明 |
|---|---|
| OPTION 位置不对 | 必须位于语句最末尾，分号之前 |
| 参数名写错或类型不匹配 | OPTIMIZE FOR里参数必须和语句中实际参数完全一致 |
| 无法绑定参数 | 参数被包在复杂表达式或IN列表里，无法用于估值 |
| 查询走的是Trivial Plan | 极简单查询可能被优化器直接降级为简单计划，部分复杂Hint被忽略 |
| Hint作用于远程表 | 四段命名跨实例查询时，部分查询提示或表提示可能失效 |
| 版本不支持 | FORCESCAN需 2008R2 SP1+，老版本直接用不了 |
比如你写了WHERE status = CASE WHEN @status = 0 THEN NULL ELSE @status END，表面上是在用@status，但SQL Server根本无法把这个表达式拆解成简单的参数引用，OPTIMIZE FOR (@status = 2)就无从谈起。这种情况只能改查询写法，或者上RECOMPILE。
5.3 经验教训：Hint不是长期的“性能拐杖”
最后分享一个我自己的教训。几年前维护一个营销活动系统，有一个报表存储过程JIT很慢，当时急于上线，我直接在存储过程头上加了WITH RECOMPILE，问题确实立刻消失。但因为没留下任何注释，后面几位接手的人都以为这是“标准写法”，于是其他新写的存储过程也照着加了。半年后系统CPU持续报警，排查才发现有二十多个存储过程全部带着RECOMPILE，大量编译开销挤压了正常查询的执行资源。
后来我花了两周时间，逐个评估性能，把其中并发最高的几个存储过程改回正常的计划缓存模式，CPU直接降了30%。那次之后我给自己定了一条规矩：Hint是紧急刹车，不是长期巡航系统。真正长期稳定的性能提升，还是来自合理的索引设计、及时的统计信息维护、以及清晰可调的查询写法。
我个人在实际排查中还有一个很小但很实用的习惯：每次加Hint都在代码里写明“添加人、日期、原因、预期移除条件”。半年后回看，这些注释往往比很多Excel文档管用得多。如果你也想在团队里落地这个习惯，建议从一个存储过程开始试点，跑通流程后再逐步推广。性能调优这件事，最怕的不是不会用工具，而是把工具当成目的。
