SQL Server R2 2008全文搜索導致'等待超時'隨機

Question

我們有一個ASP MVC網站部署到生產這是一個非常大/流行的網站，它會得到相當多的流量。

我們使用全文搜索來驅除搜索設施。

非常隨機地，我在我們的ELMAH日誌中看到一堆錯誤，「等待操作超時」。發生這種錯誤時，似乎很多顧客都是同一時間 - 例如我們會在相同的時間戳內記錄4或5個此錯誤的實例。它似乎從未孤立地發生過。

基本上，在我們的目錄頁面上，我們執行了5到6個查詢（例如'獲取所有子類別'，'獲取所有制造商'，'獲取最小/最大價格範圍'，'獲取實際產品'）和從查看堆棧跟蹤中可以看出，它將是導致異常的其中一種方法。

但是，通常情況下，他們會將用戶的篩選選項應用到每個查詢以顯示相關信息。

所以它似乎只有失敗（很少），當一個搜索詞存在。例如，當客戶查看沒有搜索字詞的目錄頁面時，我還沒有看到任何其他超時問題。

任何人都可以指出我可能發生潛在死鎖的方向嗎？我們的全文索引位於View，它從我們的產品表中提取數據。這種情況每天都會通過股票信息等進行多次更新，但視圖引入的列並不會經常更改其數據。 因爲它太隨意了，所以很難真正查明它發生的位置 - 當我導航到一個我可以看到之前導致異常的URL時，頁面加載非常快（就像搜索結果已經緩存到一定程度）。

位的詳細信息： 54612排在視圖中（2列 - 產品ID /搜索文本） SEARCHTEXT列是索引全文有95個字符最大行，所以它不是數據的巨量。大部分目錄頁面大約需要600ms才能渲染，通常這些查詢大約需要20-30ms。但是，有時候這會大大增加 - 我已經看到了執行每個查詢需要大約6秒的跟蹤，其他時間其中6個會超時並且只是非常隨機的尖峯。我從來沒有真正經歷過這種放緩，但我不經常瀏覽網站，但我們有新的遺蹟交易（和錯誤日誌），顯示頻繁減速&超時。

我們使用

@Search = '("some*" AND "search*" AND "terms*")' 

SELECT TOP ? * FROM (SELECT p.Score, [columns], [Rank] as SearchRank, ROW_NUMBER() OVER 
(ORDER BY p.Score * [Rank] DESC, p.Id DESC) AS row_number 
FROM Product p 
INNER JOIN Manufacturer AS m ON p.ManufacturerId = m.Id 
INNER JOIN ProductCategory pcm ON p.Id = pcm.ProductId 
INNER JOIN CONTAINSTABLE(vw_SearchProducts, FullSearch, @Search) AS FTS ON p.Id = FTS.[KEY] 
WHERE p.Deleted = ? AND pcm.CategoryId = @CategoryId) p WHERE p.row_number > ? ORDER BY p.Score * SearchRank DESC, p.Id DESC 

查詢和我們的觀點看起來像這樣，通過產品ID爲FTS鍵：

SELECT p.Id AS ProductId, Colour + ' ' + Size ' ' + m.Name + ' ' + Categories AS FullSearch 
FROM Product 
INNER JOIN Manufacturer m ON m.Id = p.ManufacturerId 
WHERE Deleted = 0 

我們的產品表中包含服務表現目的，一些反規範化的數據。 我們對目錄頁面的6個主要查詢都與上述類似，只是針對與過濾/搜索條件匹配的產品提取不同的數據位。

我們實際上很快升級到SQL Server 2016 - 不確定這是否會讓事情變得更好。

乾杯

Answer 1

你什麼時候開始SQL Server Profiler，讓它運行幾個小時或一天，那麼當你在日誌中再次看到超時，找到登錄SQL事件探查器在那個時候查詢和檢查時間/讀取/寫入列值。

也許這種方式，你將能夠識別具有導致超時的特定參數列表的EXACT存儲過程/語句。如果是這樣，您可以使用SSMS和執行計劃選項卡進一步調試它。

另一個想法當然是FTS目錄可能會經常重建。這也可能被困住，但你需要捕捉確切的超時時刻，然後檢查FTS目錄狀態是否正在重建。

事情應該在升級到SQL 2012-2016時改進FTS，尤其是FTS索引更新速度。 MS宣稱這種併發FTS索引更新速度提高了10倍，請參閱此答案：Are there any Sql Server Full-Text Search (FTS) performance improvements since version 2008 R2?。

55K記錄的數據真的沒那麼多。我們對數百萬條記錄運行SQL Server FTS，並且不會超時。大多數結果都在10秒以內，但這種延遲不是由FTS造成的。實際的FTS塊運行速度非常快，這是我們需要應用於初始FTS結果的額外JOIN和過濾器會導致額外的延遲。

另一個想法是你的VIEW也許設計不當，其沒有得到執行計劃由SQL Server緩存或加入到自身等爲了證實這一點，我們需要看到實際VIEW代碼，尤其是JOIN/WHERE部分。