使用参数时Azure SQL查询性能下降问题咨询

这事儿我碰到过好多次，核心原因大概率是参数嗅探（Parameter Sniffing），结合你这个包含大量分组最新记录的视图场景，咱们一步步说清楚：

1. 参数嗅探到底是什么？ #

当SQL Server第一次跑带参数的查询时，会“嗅探”这个参数的实际值，然后基于这个值生成执行计划并存进缓存。如果后续传入的参数和第一次的参数在数据分布上差很多——比如第一次用的是个极少出现的值，后来用的是高频值，或者反过来——那缓存里的执行计划就不是最优的了，自然就慢下来。

而用常量的查询不一样，每次SQL Server都会根据这个具体的常量值，精准判断对应的数据集大小，生成（或匹配）最合适的执行计划，所以速度快。

2. 你的视图让问题更明显 #

你的[Assignable Assessors]是个带大量分组取最新记录的视图，这类视图一般会用到ROW_NUMBER()窗口函数或者TOP 1的分组逻辑，执行计划本身就复杂。一旦参数嗅探生成了不合适的计划——比如本来该用索引查找，结果搞成了全表扫描——性能差距会被放大得特别明显。

3. 额外要排查的小细节 #

你说没有显式类型转换，但还是要确认下：参数@__targetLevel_4是nvarchar(8)，字段[Certificate Type ID]也是完全一样的类型吧？要是有隐性转换（比如字段是varchar参数是nvarchar，不过你说字段也是nvarchar(8)，这个概率低），也会导致索引失效，但你常量查询快，所以这个应该不是主因。

怎么验证和解决？ #

• 先确认是不是参数嗅探：给参数化查询加个OPTION (RECOMPILE)，强制每次重新生成计划，比如：

  DECLARE @__targetLevel_4 AS nvarchar(8); 
  SET @__targetLevel_4 = 'TAA'; 
  SELECT * FROM [Assignable Assessors] WHERE ([Certificate Type ID] = @__targetLevel_4)
  OPTION (RECOMPILE)
  

  如果跑起来速度和常量查询差不多，那基本实锤是参数嗅探。
• 解决办法选适合你的：
  • 用OPTION (RECOMPILE)：适合参数值分布差异大，而且查询频率不太高的场景；
  • 用本地变量：要是把这段逻辑放进存储过程，可以先把参数赋值给本地变量再查询，绕过参数嗅探；
  • 更新统计信息：视图的统计信息可能过时了，导致SQL Server判断错数据分布，跑一遍UPDATE STATISTICS [Assignable Assessors]试试；
  • 改成索引视图：如果视图的逻辑固定不变，可以考虑把它改成索引视图，提前计算好分组结果，从根本上提升查询性能。

内容的提问来源于stack exchange，提问作者Liero