為什麼數據庫不自動創建自己的索引？
我原以為數據庫對他們經常遇到的事情有足夠的了解，並且能夠響應他們所面臨的要求，他們可以決定為高度請求的數據添加索引。
更新
這現在在 SQL Server Azure 中實現。它生成建議
並且可以將索引管理配置為自動。
啟用自動索引管理
您可以將 SQL 數據庫顧問設置為自動實施建議。當推薦可用時，它們將被自動應用。與服務管理的所有索引操作一樣，如果性能影響是負面的，則建議將被恢復。
原始答案
一些數據庫已經（有點）自動創建索引。
在 SQL Server 中，執行計劃有時可以包括一個Index Spool運算符，RDBMS 在其中動態創建數據的索引副本。然而，這個假離線不是與源數據保持同步的數據庫的持久部分，它不能在查詢執行之間共享，這意味著此類計劃的執行最終可能會重複創建和刪除相同數據的臨時索引。
也許在未來，RDBMS 將能夠根據工作負載動態刪除和創建持久索引。
索引優化的過程最終只是成本效益分析。雖然原則上人類可能擁有更多關於查詢在工作負載中的相對重要性的資訊，但沒有理由不能將這些資訊提供給優化器。SQL Server 已經有一個資源管理器，它允許將會話分類到不同的工作負載組中，並根據優先級分配不同的資源。
Kenneth 提到的缺失索引 DMV 並不打算盲目實施，因為它們只考慮對特定查詢的好處，而沒有嘗試考慮潛在索引對其他查詢的成本。它也不會合併類似的缺失索引。例如，這個 DMV 的輸出可能會報告缺失的索引
A,B,C和A,B INCLUDE(C)這個想法的一些目前問題是
- 任何實際上並未創建索引的自動分析的質量將高度依賴於成本計算模型的準確性。
- 即使在自動分析領域，離線解決方案也將能夠比線上解決方案更徹底，因為線上解決方案不應向實時伺服器增加大量簿記成本並干擾其執行查詢的主要目的。
- 為響應工作負載而自動創建的索引必然是為響應那些發現它們有用的查詢而創建的，因此將落後於提前創建索引的解決方案。
預計成本模型的準確性會隨著時間的推移而提高可能是合理的，但第 2 點看起來更難解決，第 3 點本質上是不可解決的。
然而，絕大多數安裝可能並不處於這種理想化的情況下，熟練的員工會持續監控、診斷和預測（或至少對工作負載的變化做出反應）。
微軟研究院的AutoAdmin 項目自 1996 年以來一直在執行
該項目的目標是通過利用工作負載的知識使數據庫進行自我調整和自我管理
項目首頁列出了幾個有趣的項目。一個與這裡的問題特別相關
當沒有可用的 DBA（例如嵌入式數據庫或小型企業）時，會出現另一個有趣的問題。在這種情況下，低接觸連續索引調整方法可能變得很重要。我們已經探索了解決方案…
$$ in $$ICDE 2007 中的“ 物理設計調整的線上方法”。
作者說
隨著線上索引等越來越常見的 DBMS 功能，探索更自動的解決方案來解決物理設計問題以推動最先進的技術水平是很有吸引力的。
論文介紹了一種算法
其主要特點是：
- 隨著查詢的優化，我們確定了一組可以提高性能的相關候選索引。此功能允許查詢處理與在後台建構的索引並行繼續。
- 在執行時，我們會跟踪由於沒有此類候選索引而失去的潛在好處，以及在存在查詢、更新和空間限制的情況下現有索引的效用。
- 在我們收集到足夠的“證據”證明物理設計更改是有益的之後，我們會自動觸發索引的創建或刪除。
- 我們問題的線上性質意味著我們通常會落後於知道未來的最佳解決方案。然而，通過仔細衡量證據，我們確保我們不會因“遲到”的決定而受到嚴重影響，從而限制了發生的損失金額
該算法的實現允許響應伺服器負載的變化進行節流，並且如果在創建期間工作負載發生變化並且預期收益低於認為值得的點，則還可以中止索引創建。
作者關於線上與傳統物理調整的結論。
當 DBA 不確定工作負載的未來行為或無法進行全面分析或建模時，這項工作中的線上算法很有用。如果 DBA 擁有有關工作負載特徵的完整資訊，則可以通過現有工具（例如，
$$ 2, 3 $$) 將是一個更好的選擇。
這裡的結論與另一篇論文Autonomous Query-driven Index Tuning中的結論相似
如果事先知道整個工作量，我們的方法就無法擊敗索引顧問。但是，在工作負載不斷變化的動態環境中，查詢驅動的方法會產生更好的結果。
