根據執行計劃創建索引
我一直在重寫一個表現不佳的視圖 - 它有 28 個 LEFT JOIN 到另一個視圖，我設法將其修改為一個 LEFT JOIN，我們看到性能有了相當大的改進。
但是當我查看執行計劃以查看我可以在哪裡獲得更多性能時，我注意到這一點 - SQL 基本上必須讀取從這個特定表返回的記錄數的 5 倍，並且計劃資源管理器正在告訴我這就是 24% 的查詢成本的來源。
但是當我查看提到的索引時，這些是索引中包含的列（不包含列）：
所以我的問題是——當我試圖理解我在這裡看到的究竟是什麼時——我可以對現有索引做些什麼來幫助這裡的性能嗎？
我嘗試使用 Brent Ozar 的粘貼計劃，但 XML 太大了，因為 TSQL 本身大約有 800 行，所以我在我的 Google Drive 中創建了一個文件夾，其中包含 .sql 文件、.sqlplan 文件和 .pesession文件（用於哨兵一號計劃資源管理器）。
您可能會發現此答案很有幫助。索引包含查詢所需的所有列，因此它可以被查詢使用。但是，列的順序不允許使用索引鍵進行盡可能多的過濾。大約 1430 萬行使用索引查找位於索引中，但在應用謂詞過濾器後，其中近 1200 萬行被丟棄。還值得一提的是，該表只有 1070 萬行。使用嵌套循環和索引從具有 1070 萬行的表中讀取 1400 萬行可能不是最佳選擇。話雖如此，您可以通過將索引鍵順序更改為以下內容來提高索引查找效率：
- 保單號碼
- 新冠病毒
- 交易 ID
- 所有其他列
更改索引的鍵順序可能會以正面或負面的方式影響其他查詢。我不能說總體上為伺服器的工作負載做出的決定是否正確。
在查看您的查詢計劃時，我注意到了其他一些事情：
- 在查詢執行期間等待向客戶端發送結果大約花費了 164 秒（佔總執行時間的 38%）。將近一百萬行返回到 SSMS 結果網格可能需要一段時間。確保以與應用程序最相似的方式執行查詢，以獲得最準確的調整結果。您可能會發現在進行性能測試時丟棄到 SSMS 中的查詢結果集很有用。
- 大約 42 秒（總執行時間的 10%）用於等待 CPU。如果可以將查詢更改為使用更少的 CPU，如果可以使用伺服器上的其他查詢來使用更少的 CPU，或者如果伺服器的總核心數增加，則查詢將更快地完成。
- 計劃中還有其他索引查找，其中從索引中讀取的行數多於相應表中的行數。’$$ AfterShock $$.$$ dbo $$.$$ LineOfCoverage $$.$$ LineOfCoverage11 $$’ 節點 53 中的一個範例。不同的索引或連接類型可能會提高查詢的性能。
- 有一些糟糕的基數估計會導致 tempdb 溢出。解釋原因超出了本問答的範圍。該查詢相當複雜，因此將其拆分為使用臨時表的多個查詢可能會帶來更好的性能。
索引中的事務 ID 似乎不是兩個表中的前導鍵列。
您可能在 where 子句中使用事務 id 進行過濾，這是一個不等式謂詞，即 <= 或 > = 。
因此，您可能更喜歡創建一個以事務 ID 作為前導鍵列的索引，以查看這是否有助於避免溢出