索引條件下推是對使用索引從表中檢索行的一種優化。如果不使用icp，儲存引擎先遍歷索引然後去基表中去定位所需要的行，並將其返回給mysql伺服器，然後伺服器進行where條件的過濾。使用到icp後，如果where的部分列可以僅使用索引中的列來過濾，則mysql伺服器會將這部分條件下推到儲存引擎，儲存引擎使用索引條目來計算已推入的索引條件，只有滿足這個條件，才從表中讀取行。從而減少儲存引擎訪問表的次數和mysql伺服器訪問儲存引擎的次數
1、當range、ref、eq_ref和ref_or_null訪問方法需要訪問全表的行時（全表的行指的是訪問索引查出來的所有行）
2、儲存引擎是innodb或者是myisam
3、innodb中只能被用於二級索引
4、引用子查詢不能下推
5、涉及儲存功能的條件不能下推。儲存引擎無法呼叫儲存的功能
6、觸發條件不能下推
使用索引條件下推時 explan中的extra列中將出現using index condition。5.6中只要where條件中能使用到索引就會出現這個using index condition，但像單值索引或可以說只能使用到乙個索引的時候就不必進行索引條件下推優化，因為它根本沒有下乙個索引列可進行過濾，5.7中對此進行了優化，這種情況就不會出現using index condition。
根據索引下推原理，我感覺它主要就是優化了聯合索引的範圍查詢導致索引失效和跳字段導致索引失效的問題。
5.7效果比較明顯，僅使用5.7舉個例子
建立聯合索引
create index idx_name_age_position on employees(name,age,position)
舉例一:
關閉下推再次檢視
舉例2：
關閉下推再次檢視
猜測
有個現象是，開啟索引下推和關閉索引下推，explain中rows的預估掃瞄行數是一樣的，理論上下推會減少對錶的掃瞄行數，這個就有些矛盾了。
我猜測的是，rows只是mysql預估的掃瞄行數，預估的時候可能沒有考慮下推優化，只是根據使用到的索引進行預估的。具體是不是這樣那就需要研究mysql原始碼了（俺是不會去研究的）
mysql 索引 索引條件下推 ICP
索引條件下推 icp index condition pushdown,簡單的來講，使用索引查詢後，不立即進行回表查詢，通過where條件中的字段 該字段也是位於索引中 進行過濾，將過濾之後的結果進行回表查詢。相對於沒有開啟icp,減少了回表查詢的記錄數 來自官網 假設乙個表包含有關人員及其位址的資...
模糊匹配like 優化 索引條件下推ICP
mysql 5.6開始支援icp index condition pushdown 不支援icp之前，當進行索引查詢時，首先根據索引來查詢資料，然後再根據where條件來過濾，掃瞄了大量不必要的資料，增加了資料庫io操作。icp 全稱為index condition pushdown，是mysql ...
SQL 之 ICP 索引條件下推
正式講 icp 之前了，我們先將相關的概念捋一捋，知道的就當回顧，不知道的就當了解了，這有助於對 icp 的理解 建個示例表 tbl index create table tbl index c1 int,c2 int,c3 char 1 primary key c1 key idx c2 c2 如...