文章轉自：http://www.cnblogs.com/zhengyun_ustc/p/slowquery2.html
寫在前面的話：
之前曾說過“不要求每個人一定理解 聯表查詢(join/left join/inner join等)時的mysql運算過程”，但對於欄位選擇性差意味著什麼，組合索引欄位順序意味著什麼，要求每個人必須瞭解；
重複上一次的話：把mysql客戶端（如SQLyog，如HeidiSQL）放在桌面上，時不時拿出來 explain 一把，這是一種美德！
確保親手查過SQL的執行計劃，一定要注意看執行計劃裡的 possible_keys、key和rows這三個值，讓影響行數儘量少，保證使用到正確的索引，減少不必要的Using temporary/Using filesort；
不要在選擇性非常差的欄位上建索引，原因參見優化策略A；
查詢條件裡出現範圍查詢（如A>7，A in (2,3)）時，要警惕，不要建了組合索引卻完全用不上，原因參見優化策略B；
我們先回顧一下欄位選擇性的基礎知識。
——欄位選擇性的基礎知識——

引子：什麼欄位都可以建索引嗎？

如下表所示，sort 欄位的選擇性非常差，你可以執行 show index from ads 命令可以看到 sort 的 Cardinality（雜湊程度）只有 9，這種欄位上本不應該建索引：

Table

Non_unique

Key_name

Seq_in_index

Column_name

Collation

Cardinality

Sub_part

Packed

Null

Index_type

Comment

ads

1

sort

1

sort

A

9

\N

\N

BTREE

優化策略A：欄位選擇性
選擇性較低索引 可能帶來的效能問題
索引選擇性=索引列唯一值/表記錄數；
選擇性越高索引檢索價值越高，消耗系統資源越少；選擇性越低索引檢索價值越低，消耗系統資源越多；
查詢條件含有多個欄位時，不要在選擇性很低欄位上建立索引
可通過建立組合索引來增強低欄位選擇性和避免選擇性很低欄位建立索引帶來副作用；
儘量減少possible_keys，正確索引會提高sql查詢速度，過多索引會增加優化器選擇索引的代價，不要濫用索引；
再回顧組合索引與範圍查詢的業務場景。
——組合索引欄位順序與範圍查詢之間的關係——

引子：範圍查詢 city_id in (0,8,10) 能用組合索引 (ads_id,city_id) 嗎？

舉例，

ac 表有一個組合索引(ads_id,city_id)。

那麼如下 ac.city_id IN (0, 8005) 查詢條件能用到 ac表的組合索引(ads_id,city_id) 嗎？

EXPLAIN

SELECT ac.ads_id

FROM ads, ac

WHERE

  ads.id = ac.ads_id

  AND ac.city_id IN (0, 8005) 

  AND ads.status = 'online'

  AND ac.start_time<UNIX_TIMESTAMP()

  AND ac.end_time>UNIX_TIMESTAMP()
 

優化策略B：

由於 mysql 索引是基於 B-Tree 的，所以組合索引有“欄位順序”概念。

所以，查詢條件中有 ac.city_id IN (0, 8005)，而組合索引是 (ads_id,city_id)，則該查詢無法使用到這個組合索引。

DBA總結道：

組合索引查詢的各種場景
茲有 Index (A,B,C) ——組合索引多欄位是有序的，並且是個完整的BTree 索引。
下面條件可以用上該組合索引查詢：
A>5
A=5 AND B>6
A=5 AND B=6 AND C=7
A=5 AND B IN (2,3) AND C>5
下面條件將不能用上組合索引查詢：
B>5 ——查詢條件不包含組合索引首列欄位
B=6 AND C=7 ——查詢條件不包含組合索引首列欄位
下面條件將能用上部分組合索引查詢：
A>5 AND B=2 ——當範圍查詢使用第一列，查詢條件僅僅能使用第一列
A=5 AND B>6 AND C=2 ——範圍查詢使用第二列，查詢條件僅僅能使用前二列

組合索引排序的各種場景
茲有組合索引 Index(A,B)。
下面條件可以用上組合索引排序：

ORDER BY A——首列排序
A=5 ORDER BY B——第一列過濾後第二列排序
ORDER BY A DESC, B DESC——注意，此時兩列以相同順序排序
A>5 ORDER BY A——資料檢索和排序都在第一列
下面條件不能用上組合索引排序：
ORDER BY B ——排序在索引的第二列
A>5 ORDER BY B ——範圍查詢在第一列，排序在第二列
A IN(1,2) ORDER BY B ——理由同上
ORDER BY A ASC, B DESC ——注意，此時兩列以不同順序排序

順著組合索引怎麼建繼續往下延伸，請各位注意“索引合併”概念：
MySQL 5,0以下版本，SQL查詢時，一張表只能用一個索引（use at most only one index for each referenced table），
從 MySQL 5.0開始，引入了 index merge 概念，包括 Index Merge Union Access Algorithm（多個索引並集訪問），包括Index Merge Intersection Access Algorithm（多個索引交集訪問），可以在一個SQL查詢裡用到一張表裡的多個索引。
MySQL 在5.6.7之前，使用 index merge 有一個重要的前提條件：沒有 range 可以使用。[出自參考資源2]
索引合併的簡單說明：
MySQL 索引合併能使用多個索引
SELECT * FROM TB WHERE A=5 AND B=6
能分別使用索引(A) 和 (B) 或 索引合併；
建立組合索引(A,B) 更好；
SELECT * FROM TB WHERE A=5 OR B=6
能分別使用索引(A) 和 (B) 或 索引合併；
組合索引(A,B)不能用於此查詢，分別建立索引(A) 和 (B)會更好；
最後的總結：
仍然是強調再強調：
記住，explain 後再提測是一種美德！