我們遇到的最容易引起困惑的問題就是索引列的順序。正確的順序依賴于使用該索引的查詢，并且同時需要考慮如何更好地滿足排序和分組的需要（順便說明，本節內容適用于B-Tree索引；哈希或者其他類型的索引并不會像B-Tree索引一樣按順序存儲數據）。
在一個多列B-Tree索引中，索引列的順序意味著索引首先按照最左列進行排序，其次是第二列，等等。所以，索引可以按照升序或者降序進行掃描，以滿足精確符合列順序的ORDER BY、GROUP BY和DISTINCT等子句的查詢需求。
所以多列索引的順序至關重要。在“三星索引”系統中，列順序也決定了一個索引是否能夠成為一個真正的“三星索引”。
對于如何選擇索引的列順序有一個經驗法則：將選擇性最高的列放到索引最前列。這個建議有用嗎？在某些場景可能有幫助，但通常不如避免隨機IO和排序那么重要，考慮問題需要更全面（場景不同則選擇不同，沒有一個放之四海皆準的法則。這里只是說明，這個經驗法則可能沒有你想象的重要）。
當不需要考慮排序和分組時，將選擇性最高的列放在前面通常是很好的。這時候索引的作用只是用于優化WHERE條件的查找。在這種情況下，這樣設計的索引確實能夠最快地過濾出需要的行，對于WHERE子句中只使用了索引部分前綴列的查詢來說選擇性也更高。然而，性能不只是依賴于所有索引列的選擇性(整體基數)，也和查詢條件的具體值有關，也就是和值的分布有關。這和選擇前綴的長度需要考慮的地方一樣。可能需要根據那些運行頻率最高的查詢來調整索引列的順序，讓這種情況下索引的選擇性最高。

 

一個文章庫，里面有兩個表：category和article。category里面有10條分類數據。article里面有20萬條。articl