SQL Server函數間歇性性能問題

Question

我們的數據庫中有一個函數，該函數搜索兩個大表以查看值是否存在。 這是一個很大的查詢，但已對其進行了優化以使用索引，並且通常運行速度非常快。

在過去的2周中，此功能有3次決定進入麻煩境地，並且運行極其緩慢，這會導致死鎖和性能下降。 即使在少於高峰使用量的時候也會發生這種情況。

在SQL Server中使用“更改功能”重建功能似乎可以解決此問題。 完成后，服務器使用率將恢復正常，一切正常。

這使我們認為功能查詢計划已經重建，並考慮了正確的索引，但是我們不知道為什么SQL Server突然決定將查詢計划更改為更差的計划。

是否有人有什么想法可能導致這種行為，或者如何測試或預防它？ 我們正在運行SQL Server 2008 Enterprise。

Answer 1

您描述的行為通常是由於緩存了錯誤的查詢計划和/或過時的統計信息造成的。

當您在WHERE子句中有大量參數時，尤其是一長串形式的參數時，通常會發生這種情況：

(@parameter1 is NULL OR TableColumn1 = @parameter1)

假設緩存的查詢計划已過期，並且使用一組不具有代表性的參數來調用proc。 然后為該數據配置文件緩存該計划。 但是，如果proc在一組非常不同的參數中更為常見，則該計划可能不合適。 這通常被稱為“參數嗅探”。

有許多方法可以緩解和消除此問題，但是它們可能涉及折衷，並且取決於您的SQL Server版本。 看看OPTIMIZE FOR和OPTIMIZE FOR UNKNOWN 。 如果不經常調用proc（如果它很大的話），但必須盡可能快地運行，您可以將其標記為OPTION(RECOMPILE) ，以在每次調用時強制重新編譯，但不要對經常調用的proc執行此操作或未經調查。

[注意：請注意您的SQL Server 2008框具有哪個Service Pack和累積更新（CU） ，因為在某些版本中，重新編譯和參數嗅探邏輯的工作方式有所不同]

運行此查詢（來自Glenn Berry）以確定統計信息的狀態：

-- When were Statistics last updated on all indexes?
SELECT o.name, i.name AS [Index Name],  
      STATS_DATE(i.[object_id], i.index_id) AS [Statistics Date], 
      s.auto_created, s.no_recompute, s.user_created, st.row_count
FROM sys.objects AS o WITH (NOLOCK)
INNER JOIN sys.indexes AS i WITH (NOLOCK)
ON o.[object_id] = i.[object_id]
INNER JOIN sys.stats AS s WITH (NOLOCK)
ON i.[object_id] = s.[object_id] 
AND i.index_id = s.stats_id
INNER JOIN sys.dm_db_partition_stats AS st WITH (NOLOCK)
ON o.[object_id] = st.[object_id]
AND i.[index_id] = st.[index_id]
WHERE o.[type] = 'U'
ORDER BY STATS_DATE(i.[object_id], i.index_id) ASC OPTION (RECOMPILE);