索引真的會降低低容量寫入數據庫的性能嗎？
我正在嘗試對我目前正在處理的數據庫進行一些清理/審查（順便說一下，我沒有設計）。數據庫在對象方面是“大”的（數百個表、數百個 SP、函式、一千個觸發器、looooots 列等），它的設計，嗯……不是那麼好。一點都不好。因此，雖然我正在處理過去三年中客戶無用抱怨的長期積壓的表演相關問題，但我也想做一些“簡單的修復”。
現在，我發現了一些有趣的事情，比如 40% 的表沒有主鍵，30% 的表沒有索引，還有很多其他非常有趣的事情（可能會持續幾個小時），但這個問題是專注於索引。
我已經在數據庫上工作了一段時間，我知道索引可以（並且確實）在寫入期間減慢系統速度，這不足為奇。是的，索引仍然必須儲存在某個地方，因此它們會增加數據庫大小，但是……除此之外還有什麼其他的嗎？
數據庫小得離譜，每秒的寫入次數可能可以按每分鐘的寫入次數計算，而無需兩位數，所以我不關心這些點。
我編寫了一些 TSQL 來查找沒有索引和“很多”記錄的表（比如一個有四百萬條記錄而不是單個索引或主鍵/facepalm的表），另外我使用 sys.dm_db_missing_index_* 來找出 DBE 認為需要的索引。
所以，底線是：我應該繼續盲目地添加索引，還是因為我沒有預見到的某種原因而冒著破壞系統性能的風險？
您有很多問題和未知數（沒有關於數據庫大小、硬體 - RAM、CPU、磁碟（san 或本地 ssd）的資訊，是伺服器虛擬機還是物理伺服器，您是否有關於什麼看起來不錯或什麼是好的基線可接受的 sp_configure 設置，您是否在您的問題中執行維護 - 更新統計資訊、索引重組/重建等。
我應該繼續盲目添加索引嗎
不。首先閱讀這篇文章——不要盲目地創建那些“缺失”的索引！
- 閱讀後，請進行健康檢查sp_Blitz：整體健康檢查
- 審查並解決高優先級的問題。
- 調整索引 - sp_BlitzIndex：調整索引
以上將使您保持良好狀態。如果您發現任何問題，請發回問題，我們會幫助您:-)
如果數據都在堆中（根本沒有索引），那麼添加聚集索引通常會有所幫助，除非表非常小，否則堆不會幫助任何人，因為您必須每次都進行表掃描。
已經有索引的那些你想要做更多的調查，但從個人角度來看，向堆添加索引不會降低性能，因為最壞的情況是你會讓它進行表掃描，這是反正它現在在做什麼。
您確實需要計算出您想要的索引，但是，如果有像標識欄位這樣明顯的東西那麼很好，其他表（並且根據您所描述的聲音可能是一些）將在您的位置不那麼明顯想要創建您的聚集索引，請查看正在訪問該表的查詢並從那裡開始工作。
注意：向堆添加聚集索引僅佔用（足夠接近）填充因子的空間，它將替換堆，而不是向其添加完整的數據集（另請注意，如果數據庫不是，則執行此操作會更快執行其通常的流程，您可以在“離線”狀態下執行創建索引