SQL 参数减慢查询速度

Question

我有一个通过 ADO.NET 与 SQL Server 2008R2 一起使用的查询。当我使用内联 LIKE 子句时，它会在不到一秒的时间内工作，从 200 万返回 5 行。如果我像在 .NET 中那样在 SSMS 中的查询开始时声明参数，则需要很长时间。

这是同一个查询，但参数化了。

第一个（效果很好）是（效果很好）：

;WITH Results_CTE AS (
    SELECT  ld.* , ROW_NUMBER() OVER (ORDER BY PK_ID) AS RowNum  
    FROM list..List_Data ld 
    WHERE Name IS NOT NULL  AND 
    Postcode LIKE 'SW14 1xx%' 
) SELECT * FROM Results_CTE 

需要永远的第二个是：

declare @postcode varchar(10) = 'SW14 1xx'
;WITH Results_CTE AS (
    SELECT  ld.* , ROW_NUMBER() OVER (ORDER BY PK_ID) AS RowNum  
    FROM list..List_Data ld
    WHERE Name IS NOT NULL  AND 
    Postcode LIKE @postcode +'%' 
) SELECT * FROM Results_CTE 

我相信这与 SQL Server 的内部工作原理有关，但我真的不知道。

Answer 1

使用

SELECT * 
FROM Results_CTE 
OPTION (RECOMPILE)

SQL Server 不会嗅探变量的值，因此它不知道它的选择性有多大，并且可能会假设查询将返回比实际情况多得多的行，并为您提供优化的计划。

在您的情况下，我很确定在好的计划中您会发现它使用非覆盖非聚集索引来评估 PostCode 谓词和一些查找来检索丢失的列，而在坏计划中（如它猜测查询将返回更多的行数）它避免这种情况以支持全表扫描。

Answer 2

我在谷歌上搜索 C# 中 SqlCommand.Parameters.Add() 的潜在问题，我找到了这个页面。我知道这是一篇 SQL Server 帖子，但其他人可能会通过 google 找到它，它可能会帮助他们使用 C#。

对我来说，以上答案都不起作用，所以我尝试了另一种方法。

代替：

cmd.Parameters.Add(new SqlParameter("@postcode", postcode));

我用这个代替：

// Replace SqlDbType enumeration with whatever SQL Data Type you're using.
cmd.Parameters.Add("@postcode", SqlDbType.VarChar).Value = postcode;

别忘了命名空间：

using System.Data;

希望这对某人有所帮助！

Answer 3

您可以使用optimize for 让参数化查询使用与具有特定参数的查询相同的执行计划：

SELECT * 
FROM Results_CTE 
OPTION (OPTIMIZE FOR (@postcode = 'SW14 1xx'))

Answer 4

这看起来像是参数嗅探引起的问题 - 在计划编译期间 SQL Server “嗅探”当前参数值并使用它来优化查询。这可能导致的最常见问题是，如果查询在第一次运行/编译时使用“奇数”参数值运行，在这种情况下，查询计划将针对该参数值进行优化，但是参数嗅探可能会导致所有其他问题

在您的情况下，如果查询使用 @postcode 的空/null 值运行，则查询使用 LIKE '%' 子句，这很可能导致表扫描，因为正在使用 LIKE 通配符在过滤器的开头。看起来该计划最初是使用空的 @postcode 参数运行/编译的，或者 SQL Server 不知何故被此参数弄糊涂了。

您可以尝试以下几种方法：

1. 将查询标记为重新编译，然后使用@postcode 的非空值再次运行查询。
2. “屏蔽”参数以尝试防止参数嗅探，

例如：

declare @postcode varchar(10) = 'SW14 1xx'
declare @postcode_filter varchar(10) = @postcode + '%'
-- Run the query using @postcode_filter instead of @postcode

虽然这个查询看起来应该以完全相同的方式运行，但我发现 SQL Server 以奇怪的方式处理参数 - 关于何时使用参数嗅探的规则有时可能有点奇怪，所以你可能想要玩弄上述的变化。