http://blog.chinaunix.net/uid-259788-id-4146363.html
http://www.cnblogs.com/Amaranthus/p/4028687.html MYSQL 5.6手冊
http://www.cnblogs.com/hustcat/category/214566.html YY哥
http://blog.163.com/li_hx/blog/static/18399141320150253652874/ 那海藍藍
http://tech.it168.com/a2013/0506/1479/000001479749.shtml
http://www.server110.com/mariadb/201310/2245.html
http://www.cnblogs.com/zhoujinyi/p/4746483.html
http://www.codesec.net/view/159821.html
1. mrr
mrr_cost_based
這個是從MySQL 5.6 開始增加的開關。 意思是針對普通索引把資源利用最大化，主要是針對多列索引，也叫組合索引來做基本掃描，然后對匹配的記錄按照主鍵排序，這樣按照有序的主鍵順序從磁盤上掃描需要的全部記錄。 根本功能是把對磁盤的隨機掃描轉化為順序掃描。
主要針對的是數據太大，放不到CACHE里面（比如INNODB，或者MYISAM）。 目前對全索引掃描意義不大。
2. batched_key_access
（在JOIN BUFFER POOL里）當內表被掃描后，針對掃描到的記錄，找到對應的主鍵值並且一次**給MRR接口。省掉了頻繁跟磁盤交互的IO部分。
3. block_nested_loop
（在JOIN BUFFER POOL里）當內表被掃描后，針對原來的記錄加上一個是否匹配標記，生成新的記錄。這樣下次外表的值如果再來遍歷內表，就只掃描不匹配的即可。省掉部分CPU資源。
4. index_condition_pushdown
不開啟： 對於組合索引（A,B）來說，如果A可以用到索引，B不能用到，那么只能在索引樹上找到A，然后再用A對應的指針到磁盤上遍歷數據。
開啟后： 同樣對於組合索引（A,B）來說，如果A可以用到索引，B不能用到，那么在索引樹上找到A，然后再通過B的過濾條件在索引樹上進行過濾，刪選后的指針到磁盤上遍歷數據。
但是ICP並不能把隨機掃描變為順序掃描,只是減少了對磁盤交互的IO部分。
http://blog.csdn.net/wang1518037965/article/details/46550807
5. use_index_extensions
主要用於INNODB的第二索引，也就是普通的索引,把索引中包含的主鍵值利用到。比如主鍵為(a,b),索引為(c). 如果用到了索引c，那么把索引變成(c,a,b) 這樣，就可以用到新的組合索引了。
不過這種場合用的也比較少，一般是根據組合主鍵中的第一個字段和普通索引一起來做檢索的時候。
6. semijoin
表示在連接的時候內表去重的過程 。
比如對以下的查詢，a.class_id 就只需要掃描一次和b.id相同的記錄就可以不在繼續了。因為不需要關心b表里面是否有多少相同的class_id，只需要知道有還是沒有就行了。
所以一般用在對子查詢的優化居多。
http://www.cnblogs.com/xiaotengyi/p/3908347.html
http://www.linuxidc.com/Linux/2015-05/117523.htm
7. firstmatch
只選用內表的第一條與外表匹配的記錄。
8. loosescan
把內表的數據基於索引分組，取每組第一條數據即可。
9. materialization
subquery_materialization_cost_based
把內表去重然后生成有對應索引的臨時表（有點類似其他數據中的物化視圖），然后通過外表的對應鍵值遍歷這張臨時表。
主要針對不能抓華為半連接的檢索類型。