SQL 之 ICP 索引條件下推

2021-10-14 04:14:27 字數 4287 閱讀 3675

正式講 icp 之前了,我們先將相關的概念捋一捋,知道的就當回顧,不知道的就當了解了,這有助於對 icp 的理解

建個示例表 tbl_index

create table tbl_index (

c1 int,

c2 int,

c3 char(1),

primary key(c1),

key idx_c2 (c2)

);

如果 where 條件的列和 select 的列都在乙個索引中,通過這個索引就可以完成查詢,這就叫就叫覆蓋索引;當然,覆蓋索引基本針對的是組合索引(innodb 的聚簇索引有點特殊,具體可以看下面的圖)

針對上面的 tbl_index,select c2 from tbl_index where c2 = 4;是覆蓋索引查詢,但是這條 sql 沒有意義,如果我們在 tbl_index 表上增加索引index idx_c2_c3 (c2,c3),那麼select c3 from tbl_index where c2 = 4;走覆蓋索引查詢還是很有意義的,那問題又來了,覆蓋索引的意義何在 ?我們往下看

通過某個索引無法直接完成 sql 查詢(where 條件的列和 select 的列不全部存在於任何乙個索引中),那麼此時需要獲取完整的資料記錄來完成此次查詢,從索引項記錄到獲取對應的完整資料記錄的過程就叫回表;概念可能說的有些抽象,我們結合 mysql 來看看具體什麼是回表

innodb 的回表

innodb 的索引結構有些特殊,非聚簇索引(二級索引)回表到聚簇索引的過程類似如下

innodb的聚簇索引即資料,索引和資料是存在一起的;那麼直接走聚簇索引查詢的 sql 是不存在回表一說的,比如 select * from tbl_index where c1 = 10; ,只有從二級索引出發,並且二級索引獨自完成不了查詢的時候才會回表到聚簇索引完成查詢

myisam 的回表

有這樣一種說法:myisam 中的索引都是二級索引 ,其實說的是聚簇索引和二級索引的結構基本一致,只是聚簇索引有個唯一性約束

myisam 聚簇索引和二級索引,以及它們的回表過程類似如下

myisam 的回表過程指的是根據葉子節點中的資料記錄的位址來獲取完整記錄的過程,無論是聚簇索引還是二級索引都可能存在回表的過程;myisam 的回表與 innodb 還是有差別的

無論是 innodb 的回表還是 myisam 的回表,很有可能會造成額外的磁碟 io,這會嚴重影響查詢效率,覆蓋索引的目的就是盡量能夠一次完成 sql 查詢,避免有回表過程,從而提高效率

如何確認 mysql 是進行了覆蓋索引查詢,還是進行了回表查詢 ?

看 mysql 的執行計畫,如果 extra 中只有 using index 則說明使用了覆蓋索引查詢,如果 extra **現了 using index condition 或 using index & using where 則說明進行了回表查詢

index condition pushdown,mysql 5.6 中引入的一種優化策略

那麼究竟是將什麼從哪 push down 到哪,優化了什麼?要弄清楚這 4 個問題,我們需要先弄清楚 where 條件的提取與應用,具體可檢視:

where 條件會被提取成 3 部分:index key,index filter,table filter ,在 mysql 5.6 之前,並不區分 index filter 與 table filter,統統將 index first key 與 index last key 範圍內的索引記錄,回表讀取完整記錄,然後返回給 mysql server 層進行過濾。

而在 mysql 5.6 之後,index filter 與 table filter 分離,index filter 下降到引擎層(innodb和myisam)的索引層面進行過濾,減少了回表與返回 mysql server 層的記錄互動開銷,提高了 sql 的執行效率

假設我們有表:tbl_icp

create table tbl_icp (a int primary key, b int, c int, d int, e varchar(50));

create index idx_bcd on tbl_icp(b, c, d);

insert into tbl_icp values (4,3,1,1,'a');

insert into tbl_icp values (1,1,1,2,'d');

insert into tbl_icp values (8,8,7,8,'h');

insert into tbl_icp values (2,2,1,2,'g');

insert into tbl_icp values (5,2,2,5,'e');

insert into tbl_icp values (3,3,2,1,'c');

insert into tbl_icp values (7,4,0,5,'b');

insert into tbl_icp values (6,5,2,4,'f');

若沒有使用 icp,則 sql 查詢類似如下

沒有使用 icp 時,引擎層會將滿足 index key 範圍限制的所有資料記錄(示例中一共 6 條)逐條返回給 server 層,然後由 server 層應用 index filter 和 table filter (mysql 5.6 之前不區分 index filter 和 table filter),最後將滿足條件的資料返回給客戶端;

若使用 icp,則 sql 查詢類似如下

使用了 icp,server 層會將 index filter 下推到引擎層,引擎層在對 index first key 與 index last key 範圍內的索引項逐條進行過濾的時候,會應用上 index filter,對不滿足 index filter 條件的索引項直接過濾掉,無需回表操作,也無需返回給 server 層,從而提供執行效率;上圖中的索引項:3 1 1 、 3 2 1 不滿足 index filter 中的 d != 1 , 4 0 5 不滿足 c > 0 ,所以這 3 個索引項無需進行回表操作,也不需要返回給 server 層

相信到這裡,大家對 icp 的 4 個問題應該就比較清楚了

雖說 icp 能提高 sql 執行效率,但也不是任何情況下都適用的,它只適用於某些情況

1、當 sql 需要全表訪問時,icp 的優化策略可用於 range, ref, eq_ref,  ref_or_null 型別的資料訪問方式

2、只適用於 innodb 和 myisam 兩種儲存引擎

3、在 innodb 中,icp 只適用於二級索引

icp 的目的就是為了減少回表導致的磁碟 i/o,而 innodb 的聚簇索引的葉子節點存放的就是完整的資料記錄,只要索引資料被讀到記憶體了,那麼索引項對應的完整資料記錄也就讀到記憶體了,那麼通過索引項獲取資料記錄的過程就在記憶體中進行了,無需進行磁碟 i/o;也就說聚簇索引上應用 icp,不會減少磁碟 i/o,也就沒有使用的意義了

4、不支援覆蓋索引

其實和第 3 點一樣,因為覆蓋索引無需回表,icp 也就沒意義了

5、不支援子查詢條件的下推

6、不支援儲存過程條件、觸發器條件的下推

至於 icp 的優化效果,取決於在儲存引擎內通過 icp 篩選掉的資料的比例,過濾掉的資料比例大,那就效能提公升大,反之則效能提公升小

1、索引覆蓋與回表

這兩個往往是一起來考慮的,因為覆蓋索引的目的就是減少因回表產生的磁碟 i/o,從而提高執行效率

在實際應用中,我們往往也需要考慮盡可能用覆蓋索引來完成我們的 sql 查詢

2、icp的四個問題

將什麼從哪 push down 到哪,優化了什麼

將 index filter 從 server 層 push down 到了引擎層,減少了因回表產生的磁碟 i/o,也減少了與 server 層的互動,提高了 sql 執行效率

mysql 索引 索引條件下推 ICP

索引條件下推 icp index condition pushdown,簡單的來講,使用索引查詢後,不立即進行回表查詢,通過where條件中的字段 該字段也是位於索引中 進行過濾,將過濾之後的結果進行回表查詢。相對於沒有開啟icp,減少了回表查詢的記錄數 來自官網 假設乙個表包含有關人員及其位址的資...

索引條件下推優化(ICP)

索引條件下推是對使用索引從表中檢索行的一種優化。如果不使用icp,儲存引擎先遍歷索引然後去基表中去定位所需要的行,並將其返回給mysql伺服器,然後伺服器進行where條件的過濾。使用到icp後,如果where的部分列可以僅使用索引中的列來過濾,則mysql伺服器會將這部分條件下推到儲存引擎,儲存引...

模糊匹配like 優化 索引條件下推ICP

mysql 5.6開始支援icp index condition pushdown 不支援icp之前,當進行索引查詢時,首先根據索引來查詢資料,然後再根據where條件來過濾,掃瞄了大量不必要的資料,增加了資料庫io操作。icp 全稱為index condition pushdown,是mysql ...