3

我在 SQL2008 R2 中使用更改跟踪，并在尝试确定批处理中受影响的行时看到一个非常奇怪的行为，使用参数值时，存储的过程需要大约 30 秒才能运行，但是当我将文字值放入调用中时到它在 <1s 内返回的 CHANGETABLE 函数。

调用以下命令大约需要 30 秒：

DECLARE  @sync_last_received_anchor BigInt;
DECLARE  @sync_new_received_anchor BigInt;

SET @sync_last_received_anchor = 272361;
SET @sync_new_received_anchor = 273361;

SELECT [Customer].[CustomerID]
FROM dbo.tblCustomer AS [Customer] WITH (NOLOCK) 
    INNER JOIN CHANGETABLE(CHANGES [REDACTED].[dbo].[tblCustomer], @sync_last_received_anchor) AS [theChangeTable] 
    ON [theChangeTable].[CustomerID] = [Customer].[CustomerID]
WHERE ([theChangeTable].[SYS_CHANGE_OPERATION] = 'U' 
    AND [theChangeTable].[SYS_CHANGE_VERSION] <= @sync_new_received_anchor
)

但是，如下更改 CHANGETABLE 行，会将其减少到 ~1s。

    INNER JOIN CHANGETABLE(CHANGES [REDACTED].[dbo].[tblCustomer], 272361) AS [theChangeTable]

当我们运行 SP1 时，我认为 SQL2008 CU4 中发布的 CHANGETABLE 速度较慢的补丁已修复 (http://support.microsoft.com/kb/2276330)。

我很茫然，但为什么将参数更改为文字值会产生如此大的差异？

4

1 回答 1

4

存储过程很可能正在进行参数嗅探——即它认为您提供的值与它已经缓存的计划非常匹配，但它根本不是一个好的匹配。

关于如何解决这个问题有多篇文章，您可以在 DEV 环境中测试和尝试的一篇文章是这样的：

http://blogs.msdn.com/b/axperf/archive/2010/05/07/important-sql-server-change-parameter-sniffing-and-plan-caching.aspx

于 2012-01-19T21:32:25.583 回答