聚集索引排序順序是否影響性能

如果一個表的PK是一個標準的自動增量int（Id），並且檢索和更新的記錄幾乎總是更接近最大ID，那麼它會使性能有任何不同 - 是否PK聚集索引排序爲升序或降序？聚集索引排序順序是否影響性能

當創建這樣的PK時，默認情況下SSMS將索引的排序順序設置爲升序，並且由於最常訪問的行總是更接近當前最大ID，我想知道是否將排序更改爲遞減加快檢索速度，因爲記錄將自上而下排列而不是自下而上，並且接近頂端的記錄最常被訪問。

2014-10-10 Dean Kuga

看起來並不重要，Btree中的索引告訴SQL要從哪些頁面獲取數據。在這一點上，我認爲這種方向不會有任何關聯。 – Andrew 2014-10-10 18:14:48

要添加到b-tree響應中，所觸及的頁面數將與「ASC」或「DESC」相同。當規範與查詢'ORDER BY'子句匹配時，'DESC'通常是有益的。 – 2014-10-10 18:22:41

相關[這]（http://stackoverflow.com/questions/743858/sql-server-indexes-ascending-or-descending-what-difference-does-it-make）其中有幾個相當不錯的答案。 – 2014-10-10 18:29:07

我不認爲會有任何性能影響。因爲它將執行二進制搜索以訪問索引鍵，然後使用該鍵執行特定數據塊。無論哪種方式，該二進制搜索將達到O(log N)的複雜性。所以總共O(log N) + 1由於它是聚集索引，所以它實際上應該是O(log N)時間複雜度;因爲表格記錄是物理排序的，而不是具有單獨的索引頁面/塊。

來源

2014-10-10 18:23:13 Rahul

如果我在查詢中也使用OrderByDescending（Id）會怎麼樣？ – 2014-10-10 18:37:10

對於單列索引，它將以相同的方式進行，但如果將聚簇索引定義爲複合，則它可能有意義。 – Rahul 2014-10-10 18:41:32

索引使用B樹結構，所以不可以。但是如果您有一個基於多個列的索引，則需要外層最明顯的列，內層最不明顯。例如，如果你有2列（性別和年齡），你會希望年齡在內在和外在性別，因爲只有2個可能的性別，而有更多的年齡。這會影響性能。

來源

2014-10-10 18:13:44 iliketocode

這說的是相反的：http://dba.stackexchange.com/questions/33196/multicolumn-index-and-performance。它建議索引性別第一（平等測試）然後年齡（範圍測試） – Anon 2014-10-10 18:46:04

@實際上最高的答案聲稱它「無所謂」。但我可以從我自己的經驗告訴你，它絕對是。你想在外面選擇性最強。不久前我有一個查詢，我在臨時表中將索引倒退，通過這樣做，我將速度從大約3分鐘降低到<2分鐘。 – iliketocode 2014-10-10 19:17:32

@ user3738391更仔細地閱讀它：它表示如果兩個謂詞是相等性測試而不是範圍測試*，則無關緊要*。就你的情況{年齡，性別}而言，年齡範圍查詢比性別範圍查詢更可能。你的'更具選擇性的第一'想法是一個很好的經驗法則，但你選擇了一個性別差的例子，因爲它永遠不會被用作'SELECT * WHERE Gender BETWEEN'M'和'T''它總是或者是一個平等測試或不是謂詞，這意味着它應該是外部索引。 – Anon 2014-10-10 21:31:31

聚集索引排序順序是否影響性能

回答

相關問題