調整索引以獲得更好的性能
我剛剛開始了我作為 dba 的旅程，我發現我使用一個腳本發現我的數據庫索引是一團糟。他們來了：
以下是腳本告訴我的關於它們的內容：
你能給我一些關於如何解決它們的見解以及我在做這件事時應該考慮什麼（從邏輯上講）嗎？我不知道從哪裡開始。
到目前為止同意每個人的意見，最重要的索引調整是了解您的查詢案例，以便您知道正在使用哪些索引，哪些索引失去並且可能有用，以及哪些索引是浪費的。
看起來您正在使用First Responder Kit中的腳本，例如
sp_BlitzIndex這對於辨識上述索引調整類型非常有幫助。例如，它應該為您提供有關Reads每個Writes索引產生的數量的指標。讀取次數為 0 的索引通常是無用的。這意味著實際上沒有查詢正在使用該索引。讀取次數很少且寫入次數較多的索引可能不值得保留（但應在生產中刪除之前先進行測試）。在某些情況下，該索引對於不經常執行的查詢可能仍然非常重要。應該注意的是，在分析這些指標時應牢記伺服器的正常執行時間。如果您的伺服器昨天剛剛重新啟動，那麼指標將僅基於自昨天以來收集的數據（大部分）。正常執行時間至少為 6 個月或更長時間的伺服器應該有足夠的數據來安全地分析。
最後，我確實從您提供的螢幕截圖中獲得的少量資訊中看到了一些免費贈品 - 冗餘索引。擁有覆蓋表中相同欄位的多個索引是一種浪費。我在您的結果中看到的一個例子是
cod_ponto_hora_leit_vazaoandcod_ponto_hora_leit_vazao_Includes。cod_ponto_hora_leit_vazao_Includes已經涵蓋了所有相同的欄位cod_ponto_hora_leit_vazao以及包含列的一些其他案例。這意味著cod_ponto_hora_leit_vazao幾乎可以肯定可以刪除的冗餘和不必要的索引。並且在相同欄位的任何順序子集cod_ponto_hora_leit_vazao_Includes或任何其他索引上定義的任何其他索引也是冗餘的並且已經被覆蓋，因此它們很可能可以被刪除。例如，欄位上的索引將涵蓋所有與僅在上的索引或上的索引(D, C, B, A)相同的案例(D)``(D, C)，或上的索引(D, C, B)。所以在這種情況下唯一需要的索引是(D, C, B, A).我的最後建議，即使是上面推薦的確定性，也是確保在將更改部署到生產環境之前，在非生產環境中徹底測試更改。