正確的順序依賴于使用該索引的查詢,并且同時需要考慮如何更好的滿足排序和分組的需要(本節適用于B-Tree索引) 在一個多列B-Tree索引中,索引列的順序意味著首先按照最左列進行排序,其次是第二列,等等.所以,索引可以按照升序或者降序進行掃描,以滿足精確符合列順序的ORDER BY,GROUP BY和DISTINCT等子句的查詢需要 所以多列索引的列順序很重要.在三星索引系統中,列順序也決定了一個索引是否能夠成為一個真正的三星索引 對于如何選擇索引的列順序有一個經驗法則,將選擇性最高的列放到索引最前列.這個建議在大部分場景下有用,但通常不如避免隨機IO和排序那么重要,考慮問題需要全面 當不需要考慮排序和分組時,將選擇性最高的列放在前面通常是好的.然而,性能不只是依賴于所有索引列的選擇性(整體基數),也和查詢條件的具體值有關,也就是和值的分布有關 以下面的查詢為例子 ~~~ select * from payment where staff_id = 2 and customer_id = 584; ~~~ 是應該創建一個(staff_id,customer_id)索引還是應該顛倒下順序?可以跑一些查詢來確定在這個表中值的分布情況,并確定那個列的選擇性更高.先用下面的查詢預測下,看看where條件的分支對應的數據基數有多大 ~~~ select sum(staff_id = 2), sum(customer_id=584) from payment; ~~~ 根據結果,我們來決定把什么放到前面 這樣做有一個地方需要注意,查詢的結果非常依賴于選定的具體值.如果按照上述優化,可能對其他一些條件值的查詢不公平,服務器的整體性能可能變得更糟,或者其他查詢運行變得不如預期 如果是從比如pt-query-digest這樣的工具的報告中提取最差查詢,那么再按上述辦法選定的索引順序往往是非常高效的  最后,盡管關于選擇性和基數的經驗法值得研究,但是別忘了where子句中的排序,分組和范圍條件等其他因素,這些因素可能對查詢的性能造成非常大的影響