SQL Server 参数嗅探实测：同一个存储过程 2 ms 和 530 ms，2022 的 PSP 在 1 万倍倾斜下没触发，Query Store hint 不改代码 530→20 ms

存储过程 dbo.customer_summary 只有一句：SELECT COUNT(*), SUM(amount), MAX(created_at) FROM orders WHERE customer_id = @cid。我每轮先 DBCC FREEPROCCACHE（只在测试库），再按不同顺序调用，SET STATISTICS IO, TIME ON 记录读数和耗时。

小客户（cid=12）先编译时，优化器按 50 行估算，选了索引 Seek + Key Lookup 的串行计划。小客户只要 157 次读（首次 166），大客户沿用这个计划，要对 50 万行逐行回表，1532120 次读、510–530 ms，复跑一轮 514–527 ms。大客户先编译时，选的是并行聚集索引扫描，除 Parallelism 外的算子都是批模式，29957 次读、15–25 ms；小客户用这个计划也只要 12–14 ms，只是 CPU 时间 85–98 ms。

线上最常见的描述是：这个过程平时 1 秒内，偶尔几十秒，DBCC FREEPROCCACHE 或重建统计信息后就好了，过几天又犯。我用下载区只读 SQL 的第 2 段看 sys.dm_exec_query_stats：这条语句 min_logical_reads 190、max_logical_reads 1594620，比值 8392.7；再从计划 XML 里取 ParameterCompiledValue，是 (12)，说明缓存里的计划是用小客户编译的。

跑这段 SQL 时我踩了一个坑：sqlcmd 默认 QUOTED_IDENTIFIER OFF，调用 XML 的 .value()/.nodes() 报 Msg 1934。要加 -I，或在 SSMS 里跑。

我原以为兼容级别 160 会自动拆计划。可无论先用谁编译，sys.query_store_query_variant 都是空的，计划还是单一的一个。数据库作用域配置 PARAMETER_SENSITIVE_PLAN_OPTIMIZATION 是 1，确认是打开的。

我建了一个扩展事件会话抓 parameter_sensitive_plan_optimization_skipped_reason，再调用一次，事件给出 reason=SkewnessThresholdNotMet、reason_code=30。DBCC SHOW_STATISTICS 看直方图只有 6 个步长：RANGE_HI_KEY=1 的 EQ_ROWS 是 500000，其余步长的 AVG_RANGE_ROWS 都是 50。倾斜是 1 万倍，但没达到 PSP 的阈值。

于是我又建了 orders_skew：customer_id=1 有 100 万行，另外 2 万个客户各 5 行（20 万倍）。这次 PSP 触发了：Query Store 里出现 1 个调度计划（parent query 41）和 2 个查询变体（42、43），小客户 18 次读，大客户 32948 次读、17–26 ms（复跑 21–35 ms），不再互相拖累。所以 PSP 能不能救你，要先用这个扩展事件在自己的数据上确认。

每种修法都在清空计划缓存后先用 cid=12、再用 cid=1 调用，这正是线上出问题的顺序。

OPTION(RECOMPILE)：每次按实际参数编译，编译约 1 ms，小客户 166 读 1–2 ms，大客户 29957 读 16–31 ms。代价是每次都编译，调用频率每秒上千次的过程要先算 CPU 账。

OPTIMIZE FOR UNKNOWN：按密度向量估算（平均每个客户约 100 行），选中的仍是 Seek + Key Lookup，大客户 1532120 读、538/547 ms，复跑 475/599 ms。在这种一个大户加一堆小户的分布下，平均值偏向小户，它就和小客户先编译的结果一样。

Query Store hint：从 sys.query_store_query_text 找到这条语句的 query_id（本次是 33），EXEC sys.sp_query_store_set_hints @query_id = 33, @query_hints = N'OPTION(RECOMPILE)'。不改存储过程，效果和改代码一样：小客户 166 读 1–3 ms，大客户 29957 读 17–23 ms。实验后我用 sp_query_store_clear_hints 清掉了。

我第一反应是加覆盖索引，去掉 Key Lookup：CREATE INDEX ... ON orders(customer_id) INCLUDE(amount, created_at)，索引从 14904 KB 涨到 43784 KB。小客户先编译后，大客户的逻辑读从 1532120 降到 1799，看 STATISTICS IO 像是修好了；可耗时还是 222–231 ms（复跑 182–212 ms）。计划是串行、行模式的 Stream Aggregate，50 万行一行一行地聚合。

换成大客户先编译，同一个索引上是串行批模式 Hash Match，46–48 ms（复跑 44–48 ms），小客户 5 次读。也就是说覆盖索引减少了 IO，但计划依然取决于编译时的参数，嗅探问题还在，只是没那么严重。

我想知道快计划里批模式（2019 起的 batch mode on rowstore）贡献多少，就在同一条语句上分别加 hint 对比：OPTION(USE HINT('DISALLOW_BATCH_MODE')) 仍是并行扫描，29957 读、19–22 ms，基本不变；OPTION(MAXDOP 1) 变成串行，29523 读、95–130 ms。这台机器上，速度主要来自并行。生产上如果 MAXDOP 设成 1 或者 cost threshold for parallelism 设得很高，大客户先编译时的计划也不会这么快。

下载区的只读 SQL 只有 SELECT/WITH，需要 VIEW SERVER STATE（2022 起为 VIEW SERVER PERFORMANCE STATE）和库内读取 Query Store 的权限，用 sqlcmd -I 运行。演示脚本会建 sniff_lab 库、清计划缓存、挂和清 Query Store hint，只能在测试实例上跑。