不知道這樣的解釋合不合理，原文是對於要經常查詢的含量大量數據的數據庫，建立索引是非常重要的，建立索引一般都是在where語句用得較多的列上。現在有個問題，如果一個表有多個列需要建立索引，是把所有列建成一個索引，還是對每一個列建一個索引，上篇文章做了一個介紹，這是作者得出的結論，Conclusion: For benchmarked querIEs we can see Multiple Column index beats Index Merge in all cases when such index can be used. It is also worth to watchout a MySQL may decide not to do Index merge (either intersection or union) but instead do full table scan or Access table picking only one index on the pair.意思應該是說對多個列建索引比對每個列分別建索引更有優勢，而且要知道索引建立得越多就越占磁盤空間，在更新數據的時候速度會更慢。 另外一篇文章則介紹了如何去建立一個多列索引，最重要的一個問題是如何安排列的順序是至關重要的，比如需要對一個表裡面的兩個字段foo,bar建一個索引，那麼索引的順序是（foo,bar)還是(bar,foo)呢。在搞清楚如何安排順序之前先了解一個概念，cardinality:金山的翻譯是"集的勢"，比如，tb表有1700條記錄，foo字段有750個不同的記錄，那麼就可以說We have a cardinality of 750 for foo。總規則可以說是cardinality越大的字段應該排在索引的第一位就是說索引的位置是(foo,bar)，因為cardinality越大那麼第一次取出來的記錄集就越小，再進行第二次查詢的次數就越少了。不過這只是對於建兩個索引的規則，如果是三個以上就沒有那麼簡單了，具體地看原文，有比較詳細的例子。還需要提出的是即使我們建了一個很有效的索引，但是查詢優化器也許會選擇不用它，如果它會考慮更多因素以決定這個索引是否有足夠的效率。It was also pointed out to me, that even if an efficIEnt multi-column index is created, the query optimizer may choose to never use it. This is because the optimizer looks at further statistics to determine if the index would be efficIEnt enough or not. 另外，還可以參考一下mysql的官方文檔，http://dev.MySQL.com/doc/refman/5.0/en/multiple-column-indexes.Html，也有比較詳細的介紹MySQL如何使用索引的，只是都是e文，慢慢啃就好了。
