SQL Server：桌面掃描如何在一張小桌子上如此昂貴？

Question

我正在從一個麻煩的查詢看執行計劃。

我可以看到，計劃的45％被佔用，對具有七（7）行數據的表進行表掃描。

我即將把一個聚簇索引覆蓋在我的查詢中有7行的表上的列，它感覺...錯了。鑑於桌子太小，我的查詢這部分怎麼能佔據這麼多的計劃呢？

我在讀here，它覺得這可能只是因爲非連續的數據 - 在所討論的表中根本沒有索引。總的來說，雖然我們的數據庫很大（7GB）並且很忙。

我很想知道別人怎麼想 - 謝謝！

編輯：

查詢運行非常頻繁，並參與了僵局（和選擇作爲受害者）。目前運行需要300ms到500ms，但數據庫更忙時需要更長的時間。

查詢：

select l.team1Score, l.team2Score, ls.team1ExternalID, ls.team2ExternalID, et.eventCategoryID, e.eventID, ls.statusCode 
from livescoretracking l(nolock) 
inner join liveScores ls (nolock) on l.liveScoreID = ls.liveScoreID 
inner join db1.dbo.events e on e.gameid = ls.gameid 
inner join db1.dbo.eventtype et (nolock) on e.eventTypeID = et.eventTypeID 
inner join eventCategoryPayTypeMappings ecb (nolock) on (et.eventCategoryID = ecb.eventCategoryID and e.payTypeID = ecb.payTypeID and ecb.mainEvent = 1) 
where ls.gameID = 286711 order by l.dateinserted 

的問題表是eventCategoryPayTypeMappings表 - 謝謝！

Answer 1

在不知道實際總成本的情況下，百分比成本毫無意義。例如如果查詢花費1毫秒來執行表掃描的45％成本爲0.45毫秒，這不值得嘗試優化，但如果查詢需要10秒鐘執行，那麼45％的成本是顯着的並且值得優化。

Answer 2

這實際上取決於查詢從開始到結束需要多長時間。 45％並不意味着花費很長時間，如果查詢只是說10毫秒。它所說的大部分時間都花在了桌面掃描上，這是可以理解的。

有一個索引可能有助於表增長時，除非你知道這個表不會增長。但是，您會發現將索引添加到具有7條記錄的表格對性能幾乎沒有影響。

Answer 3

對七行表進行表掃描並不昂貴。禁止查詢提示，查詢引擎將在這樣一個小表上使用表掃描，而不管存在哪些索引。你能向我們展示更多關於有問題的查詢和執行計劃的問題嗎？

Answer 4

如果表上沒有索引，查詢引擎將會總是必須做表掃描。沒有其他方式可以處理數據。

許多RDBMS平臺都會對一個小表進行表掃描，即使是索引也是如此。 （我不確定SQL Server的具體情況。）

我會更關心查詢計劃中的實際數字。

Answer 5

對小表進行表掃描並不是一件壞事 - 如果它適合單次讀入緩存，優化器將計算表掃描的成本低於通過索引鏈讀取的成本。

我只會建議一個聚集索引，如果你想幫助確保內容'傾向'按這種方式排序（儘管你需要明確的順序來保證這一點）。

Answer 6

死鎖通常更多地表示資源訪問排序問題，而不是查詢設計問題。我會查看死鎖中的其他參與者，並查看每個事務鎖定的對象，這些對象是其他對象需要的。如果您可以重新排序以確保一致的訪問順序，則可以完全避免爭用問題。