一、Index Condition Pushdown(ICP)
Index Condition Pushdown (ICP)是mysql使用索引從表中檢索行數據的一種優化方式，從mysql5.6開始支持，mysql5.6之前，存儲引擎會通過遍歷索引定位基表中的行，然后返回給Server層，再去為這些數據行進行WHERE后的條件的過濾。mysql 5.6之后支持ICP后，如果WHERE條件可以使用索引，MySQL 會把這部分過濾操作放到存儲引擎層，存儲引擎通過索引過濾，把滿足的行從表中讀取出。ICP能減少引擎層訪問基表的次數和 Server層訪問存儲引擎的次數。
-
ICP的目標是減少從基表中讀取操作的數量，從而降低IO操作
-
對於InnoDB表，ICP只適用於輔助索引
-
當使用ICP優化時，執行計划的Extra列顯示Using indexcondition提示
-
數據庫配置 optimizer_switch="index_condition_pushdown=on”;
使用場景舉例
輔助索引INDEX (a, b, c)
SELECT * FROM peopleWHERE a='12345' AND b LIKE '%xx%'AND c LIKE '%yy%';
若不使用ICP：則是通過二級索引中a的值去基表取出所有a='12345'的數據，然后server層再對b LIKE '%xx%'AND c LIKE '%yy%' 進行過濾
若使用ICP：則b LIKE '%xx%'AND c LIKE '%yy%'的過濾操作在二級索引中完成，然后再去基表取相關數據
ICP特點
-
mysql 5.6中只支持 MyISAM、InnoDB、NDB cluster
-
mysql 5.6中不支持分區表的ICP，從MySQL 5.7.3開始支持分區表的ICP
-
ICP的優化策略可用於range、ref、eq_ref、ref_or_null 類型的訪問數據方法
-
不支持主建索引的ICP（對於Innodb的聚集索引，完整的記錄已經被讀取到Innodb Buffer，此時使用ICP並不能降低IO操作）
-
當 SQL 使用覆蓋索引時但只檢索部分數據時，ICP 無法使用
-
ICP的加速效果取決於在存儲引擎內通過ICP篩選掉的數據的比例
二、Multi-Range Read (MRR)
MRR 的全稱是 Multi-Range Read Optimization，是優化器將隨機 IO 轉化為順序 IO 以降低查詢過程中 IO 開銷的一種手段，這對IO-bound類型的SQL語句性能帶來極大的提升，適用於range ref eq_ref類型的查詢
MRR優化的幾個好處
使數據訪問有隨機變為順序，查詢輔助索引是，首先把查詢結果按照主鍵進行排序，按照主鍵的順序進行書簽查找
減少緩沖池中頁被替換的次數
批量處理對鍵值的操作
在沒有使用MRR特性時
第一步 先根據where條件中的輔助索引獲取輔助索引與主鍵的集合，結果集為rest
select key_column, pk_column from tb where key_column=x order by key_column
第二步 通過第一步獲取的主鍵來獲取對應的值
for each pk_column value in rest do: select non_key_column from tb where pk_column=val
使用MRR特性時
第一步 先根據where條件中的輔助索引獲取輔助索引與主鍵的集合，結果集為rest
select key_column, pk_column from tb where key_column = x order by key_column
第二步 將結果集rest放在buffer里面(read_rnd_buffer_size 大小直到buffer滿了)，然后對結果集rest按照pk_column排序，得到結果集是rest_sort
第三步 利用已經排序過的結果集，訪問表中的數據，此時是順序IO.
select non_key_column fromtb where pk_column in (rest_sort)
在不使用 MRR 時，優化器需要根據二級索引返回的記錄來進行“回表”，這個過程一般會有較多的隨機IO, 使用MRR時，SQL語句的執行過程是這樣的：
-
優化器將二級索引查詢到的記錄放到一塊緩沖區中
-
如果二級索引掃描到文件的末尾或者緩沖區已滿，則使用快速排序對緩沖區中的內容按照主鍵進行排序
-
用戶線程調用MRR接口取cluster index，然后根據cluster index 取行數據
-
當根據緩沖區中的 cluster index取完數據，則繼續調用過程 2) 3)，直至掃描結束
通過上述過程，優化器將二級索引隨機的 IO 進行排序，轉化為主鍵的有序排列，從而實現了隨機 IO 到順序 IO 的轉化，提升性能
此外MRR還可以將某些范圍查詢，拆分為鍵值對，來進行批量的數據查詢，如下：
SELECT * FROM t WHERE key_part1 >= 1000 AND key_part1 < 2000AND key_part2 = 10000;
表t上有二級索引(key_part1, key_part2)，索引根據key_part1,key_part2的順序排序。
若不使用MRR：此時查詢的類型為Range，sql優化器會先將key_part1大於1000小於2000的數據取出，即使key_part2不等於10000，帶取出之后再進行過濾，會導致很多無用的數據被取出
若使用MRR：如果索引中key_part2不為10000的元組越多，最終MRR的效果越好。優化器會將查詢條件拆分為（1000,1000），（1001,1000），... （1999,1000）最終會根據這些條件進行過濾
相關參數
當mrr=on,mrr_cost_based=on，則表示cost base的方式還選擇啟用MRR優化,當發現優化后的代價過高時就會不使用該項優化
當mrr=on,mrr_cost_based=off，則表示總是開啟MRR優化
SET @@optimizer_switch='mrr=on,mrr_cost_based=on';
參數read_rnd_buffer_size 用來控制鍵值緩沖區的大小。二級索引掃描到文件的末尾或者緩沖區已滿，則使用快速排序對緩沖區中的內容按照主鍵進行排序
三、Batched Key Access (BKA) 和 Block Nested-Loop(BNL)
Batched Key Access (BKA) 提高表join性能的算法。當被join的表能夠使用索引時，就先排好順序，然后再去檢索被join的表，聽起來和MRR類似，實際上MRR也可以想象成二級索引和 primary key的join
如果被Join的表上沒有索引，則使用老版本的BNL策略(BLOCK Nested-loop)
BKA原理
對於多表join語句，當MySQL使用索引訪問第二個join表的時候，使用一個join buffer來收集第一個操作對象生成的相關列值。BKA構建好key后，批量傳給引擎層做索引查找。key是通過MRR接口提交給引擎的（mrr目的是較為順序）MRR使得查詢更有效率。
大致的過程如下:
-
BKA使用join buffer保存由join的第一個操作產生的符合條件的數據
-
然后BKA算法構建key來訪問被連接的表，並批量使用MRR接口提交keys到數據庫存儲引擎去查找查找。
-
提交keys之后，MRR使用最佳的方式來獲取行並反饋給BKA
BNL和BKA都是批量的提交一部分行給被join的表，從而減少訪問的次數，那么它們有什么區別呢？
-
BNL比BKA出現的早，BKA直到5.6才出現，而NBL至少在5.1里面就存在。
-
BNL主要用於當被join的表上無索引
-
BKA主要是指在被join表上有索引可以利用，那么就在行提交給被join的表之前，對這些行按照索引字段進行排序，因此減少了隨機IO，排序這才是兩者最大的區別，但是如果被join的表沒用索引呢？那就使用NBL
BKA和BNL標識
Using join buffer (Batched Key Access)和Using join buffer (Block Nested Loop)
相關參數
BAK使用了MRR，要想使用BAK必須打開MRR功能，而MRR基於mrr_cost_based的成本估算並不能保證總是使用MRR，官方推薦設置mrr_cost_based=off來總是開啟MRR功能。打開BAK功能(BAK默認OFF)：
SET optimizer_switch='mrr=on,mrr_cost_based=off,batched_key_access=on';
BKA使用join buffer size來確定buffer的大小，buffer越大，訪問被join的表/內部表就越順序。
BNL默認是開啟的，設置BNL相關參數：
SET optimizer_switch=’block_nested_loop’
支持inner join, outer join, semi-join operations,including nested outer joins
BKA主要適用於join的表上有索引可利用，無索引只能使用BNL
四、總結
ICP（Index Condition Pushdown）
Index Condition Pushdown是用索引去表里取數據的一種優化，減少了引擎層訪問基表的次數和Server層訪問存儲引擎的次數，在引擎層就能夠過濾掉大量的數據，減少io次數，提高查詢語句性能
MRR（Multi-Range Read）
是基於輔助/第二索引的查詢，減少隨機IO，並且將隨機IO轉化為順序IO，提高查詢效率。
-
不使用MRR之前(MySQL5.6之前)，先根據where條件中的輔助索引獲取輔助索引與主鍵的集合，再通過主鍵來獲取對應的值。輔助索引獲取的主鍵來訪問表中的數據會導致隨機的IO(輔助索引的存儲順序並非與主鍵的順序一致)，隨機主鍵不在同一個page里時會導致多次IO和隨機讀。
-
使用MRR優化(MySQL5.6之后)，先根據where條件中的輔助索引獲取輔助索引與主鍵的集合，再將結果集放在buffer(read_rnd_buffer_size 直到buffer滿了)，然后對結果集按照pk_column排序，得到有序的結果集rest_sort。最后利用已經排序過的結果集，訪問表中的數據，此時是順序IO。即MySQL 將根據輔助索引獲取的結果集根據主鍵進行排序，將無序化為有序，可以用主鍵順序訪問基表，將隨機讀轉化為順序讀，多頁數據記錄可一次性讀入或根據此次的主鍵范圍分次讀入，減少IO操作，提高查詢效率。
Nested Loop Join算法
將驅動表/外部表的結果集作為循環基礎數據，然后循環該結果集，每次獲取一條數據作為下一個表的過濾條件查詢數據，然后合並結果，獲取結果集返回給客戶端。Nested-Loop一次只將一行傳入內層循環, 所以外層循環(的結果集)有多少行, 內存循環便要執行多少次，效率非常差。
Block Nested-Loop Join算法
將外層循環的行/結果集存入join buffer, 內層循環的每一行與整個buffer中的記錄做比較，從而減少內層循環的次數。主要用於當被join的表上無索引。
Batched Key Access算法
當被join的表能夠使用索引時，就先好順序，然后再去檢索被join的表。對這些行按照索引字段進行排序，因此減少了隨機IO。如果被Join的表上沒有索引，則使用老版本的BNL策略(BLOCK Nested-loop)。
參考：
http://dev.mysql.com/doc/refman/5.7/en/select-optimization.html
http://www.kancloud.cn/taobaomysql/monthly/117959