如果數據庫只有一次插入，那麼索引每個可能的列組合是否很糟糕？
我正在開發一個需要大量選擇查詢的報告系統，但它基於一個只填充一次的數據庫。數據庫管理系統是 Microsoft SQL Server 2017。可能有更好的方法來設計這樣的系統，但讓我們從理論上解決這個問題。
從理論上講：
- 如果我們有一個非常大的數據庫（幾張表上有 150M+ 行）
- 我們可以假設數據庫只會被填充一次。
索引每個可能的列組合會對選擇查詢產生負面的性能影響嗎？
是的，它會影響初始計劃編譯時間，因為優化器將有許多額外的數據訪問路徑需要考慮。
既然您使用的是 SQL Server 2017，只需載入一次並執行報表，為什麼不直接使用聚集列儲存索引呢？
這似乎是您需要索引每個可能的列組合的理想解決方案。
如果表中有 N 列，則每個可能的列組合都是 2^N-1（刪除空集）。對於 10 列，這意味著 1023 個索引，對於 20 列，我們最終會得到高達 1048575 個索引。大多數索引永遠不會被使用，但必須由優化器考慮。優化器可能會選擇次優索引而不是更好的索引。我不會採取生成各種索引的路徑，而是試圖找出哪些索引實際上是有益的。
編輯更正的可能索引數
正如Jeff指出的那樣，它甚至比 2^N（冪集）更糟糕，因為 (3,2,1) 明顯不同於 (1,2,3)。對於 N 列，我們可以選擇索引中的第一個位置，該索引包含 N 種方式的所有列。對於 N-1 種方式中的第二個位置，依此類推。因此，我們最終得到 N！全尺寸的不同索引。這些索引中沒有一個被該集合中的另一個索引所包含。此外，我們不能添加另一個較短的索引，使其不被任何完整索引覆蓋。因此索引的數量是 N!。因此，10 列的範例變為 10！= 3628800 個索引和 20 個（鼓）2432902008176640000 個索引。這是一個大得離譜的數字，如果我們在每一個 1 毫米的零件上放置一個點，那麼一束光束需要 94 天才能通過所有點。所有和所有，不要;-)