令我有一個表像這樣：SQL Server聚集索引 - 索引問題
keyA keyB data
科亞和KEYB在一起是獨一無二的，是我的表的主鍵，構成了一個聚集索引。
keyB有5個可能的值，但keyA的可能值的數量不受限制。 keyB通常遞增。
例如，下面的數據可以通過2種方式，這取決於鍵列排在第一位下令：
keyA keyB data
A 1 X
B 1 X
A 3 X
B 3 X
A 5 X
B 5 X
A 7 X
B 7 X
或
keyA keyB data
A 1 X
A 3 X
A 5 X
A 7 X
B 1 X
B 3 X
B 5 X
B 7 X
我需要告訴聚集索引，其中關鍵字列的可能值較少，因此它可以首先按該值排序數據？或者，首先排序的表現無關緊要？
你應該爲了你的複合聚集索引最有選擇性的列第一。這意味着與總行數相比，具有最明顯值的列。
「B *樹索引提高是從表中選擇行的一小部分查詢的性能。」 http://www.akadia.com/services/ora_index_selectivity.html？
本文適用於Oracle，但仍然相關。另外，如果您有一個持續運行並返回少量字段的查詢，則可以考慮創建一個包含所有字段的組合索引 - 它不必訪問基本表，而是將索引中的數據。在確保組合索引提的第一列
ligget78的評論重要的是要記住。
您可以做的最好的事情是嘗試兩種解決方案並測量執行時間。
根據我的經驗，索引調整隻是精確的科學。
也許有KEYB科亞之前在索引列的順序將是更好
我相信，SQL Server的下單吧正是你告訴它的方式。它假定你最清楚如何訪問你的索引。
在任何情況下，我都會說這是一個好主意，在可能的情況下可以指定您想要的內容，而不是希望數據庫能夠找到它。
您也可以嘗試兩種方式，運行一系列具有代表性的查詢，然後比較生成的執行計劃以確定哪個最適合您。
給了這個upvote，但只是想指出，雖然這是很好的指定你想在這種情況下，通常你應該讓服務器找出什麼是最好的。例如，在查詢中使用索引提示通常是一個壞主意，因爲最好的計劃可能會隨着數據的變化而變化。 – 2008-12-05 15:31:38
如果你用（keyA，keyB）創建一個索引（不管是否聚類），那麼這就是如何排序數值的。第一個keyA，然後是keyB（這是你問題中的第二個例子）。如果你想換個角度，你需要指定（keyB，keyA）。
它可能在性能方面很重要，當然取決於您的查詢。例如，如果你有（keyA，keyB）索引，並且查詢看起來像WHERE keyB = ...（沒有提到keyA），那麼索引不能被使用。
按照您通常希望在報告和查詢中排序的順序指定列。
雖然我會對創建多列聚集索引保持警惕。取決於它的寬度，可能會對您創建的任何其他索引的大小產生巨大影響，因爲所有非聚簇索引都包含聚簇索引值。而且，如果值經常變化，則行必須重新排序，並且我的經驗是，非代理鍵往往更頻繁地變化。因此，如果您有可能更改的值，則將其創建爲羣集非聚集索引可能會耗費更多的服務器資源時間。我不是說你不應該這樣做，因爲我不知道你的列實際包含的是什麼類型的數據（儘管我懷疑它們比A1，a2等更復雜）;我說你需要考慮這樣做的後果。在做這件事之前，徹底閱讀BOL有關集羣副非索引索引可能是一個好主意。
正如其他人所說，順序是根據你如何在索引創建腳本（或PK約束）指定。關於聚集索引的一點是，有很多事情需要記住。
您可能會通過使用比PK其他的東西你的聚集索引更好的整體性能。例如，如果您正在編寫財務系統並且報告幾乎總是基於活動的日期和時間（過去一年的所有活動等），那麼該日期列上的聚集索引可能會更好。正如HLGEM所說，排序也會受到您選擇聚集索引的影響。
聚集索引也可以影響比其他指標更插件。如果你有大量的插入，而你的聚集索引就像是一個IDENTITY列，那麼這個特定部分的磁盤可能會出現爭用問題，因爲所有的新行都被插入到同一個地方。
對於小查找表我一直只是把對PK聚集索引。對於高影響力表格，儘管在選擇最佳表格之前花時間思考（並測試）各種可能的聚集索引是一個好主意。
記住，聚集索引是在該表被存儲在磁盤上的物理順序。
所以，如果您的聚集索引的定義是可樂，COLB查詢會更快，當以同樣的順序爲您的聚集索引。如果SQL必須訂購B，那麼它需要執行後期排序以實現正確的訂單。
我的建議是在B，A添加第二非聚簇索引。還取決於您的數據列的大小INCLUDE（讀取包含列），以防止需要鍵查找。當然，假設這張表格沒有大量插入，因爲您總是必須平衡查詢速度和寫入速度。
實際上，你的聚集索引應表示其中數據是最有可能被訪問，以及保持插入\ IO更新成本的微妙平衡的順序。如果您的聚集索引是不斷插入到頁面中間的，您可能會遭受性能損失。
像其他人說，不知道該表的長度，列大小等，沒有正確的答案。用大量的測試進行試驗和錯誤是你最好的選擇。
萬一這不是很明顯的：你指數的排序順序不承諾很多有關結果的排序順序在查詢。
在查詢中，你還必須加一個
ORDER BY KeyA, KeyB
或
ORDER BY KeyB, KeyA
優化程序可能會很高興地發現需要的和節省一些時間在指數已經實際訂購的數據，但是每個應該以特定順序傳遞數據的查詢在其末尾必須具有ORDER BY子句。如果沒有命令，SQL Server不會對記錄集的順序做出任何承諾，甚至不會以從查詢到查詢的相同順序返回。
是的，你應該建議，通常查詢引擎試圖找出最佳執行計劃和索引來利用，但有時最好是強制查詢引擎使用特定索引。規劃索引時以及在查詢中使用索引時還有一些其他考慮因素。例如，索引中的列排序，where子句中的列排序。您可以參考以下鏈接瞭解：
http://ashishkhandelwal.arkutil.com/sql-server/quick-and-short-database-indexes/
我相信這將幫助您規劃索引。
它實際上是基於具體的科學思想。瞭解一下b-tree索引如何工作會讓你知道更多的信息，並且需要更少的猜測工作。 – Sam 2008-12-05 16:02:19
誠實的+1。除非您確切知道SQL Server如何在內部工作，否則無法確定實際情況如何。 理論雖然很棒。沒有，真的;） – 2008-12-06 14:41:39