在《MySQL 常見語句加鎖分析》一文中，我們詳細講解了 SQL 語句的加鎖原理并具體分析了大部分的簡單 SQL 語句，但是實際業務場景中 SQL 語句往往及其復雜，包含多個條件，此時就需要具體分析SQL 使用到的索引，并了解 where 條件的判斷邏輯。

我們可以直接使用 explain 或者 optimizer_trace 來分析 SQL 語句執行使用了哪些索引，具體使用可以看本系列文章的前兩篇文章。但是，今天我們講一下具體 Where 語句的條件的拆分和使用，即復雜 Where 條件是如何生效的。

用何登成大神的原話，就是

給定一條SQL，where條件中的每個子條件，在SQL執行的過程中有分別起著什么樣的作用？

具體場景

我們使用下面這張 book 表作為實例，其中 id 為主鍵，ISBN（書號）為二級唯一索引，Author（作者）為二級非唯一索引，score（評分）無索引。

Index Key 和 Table Filter

基于上述表，我們具體分析一下如下擁有復雜 Where 條件的 SQL 語句。

mysql> UPDATE book SET score = 9.0 WHERE Author = 'Tom' AND ISBN > 'N0004' AND ISBN < 'N0007';

上述 SQL 語句的 Where 條件使用了兩個索引，分別是二級唯一索引 ISBN 和二級非唯一索引 Author。MySQL 會根據索引選擇性等指標選擇其中一個索引來使用，而另外一個沒有被使用的 Where 條件就被當做普通的過濾條件，一般稱被用到的索引稱為 Index Key，而作為普通過濾的條件則被稱為 Table Filter。比如上面這條SQL 使用 ISBN索引來查詢，則 ISBN 就是 Index Key，而 Author = 'Tom' 這個條件就是 Table Filter。

所以，該 SQL 執行的過程就是依次將 Index Key 范圍內的索引記錄讀取，然后回表讀取完整數據記錄，然后返回給MySQL的服務層按照 Table Filter 進行過濾。至于加鎖，如下圖所示則需要將涉及的 Index Key 對應的索引記錄都進行加鎖。

但是當使用的索引是復合索引時，則還可能出現 Index Filter，利用它可以減少回表次數和返回給 MySQL 服務層的記錄的數量，降低存儲引擎和服務層的交互開銷，提高 SQL 的執行效率。

Index Filter

假設我們在 book 表的 ISBN 和 Author 列上建立了聯合索引，并且上述 SQL 執行時選擇了該復合索引。

對于這個場景，MySQL 依然使用 ISBN > 'N0004' AND ISBN < 'N0007' 條件來確定 SQL 查詢在索引中的連續位置，但是 Author = 'Tom' 可以用來直接過濾索引，即該條件可以使用復合索引來直接過濾條件，不需要讀取所有數據后由MySQL 服務層根據 Table Filter 來過濾。這就是傳說中的 ICP(Index Condition Pushdown，索引下推)技術，使用 Index Filter 過濾不滿足條件的記錄，無需加鎖。

根據 Index Key 判斷查詢返回和根據 Index Filter 進行初步過濾后，存儲引擎將剩下的數據記錄返回給服務層，再由服務層根據 Table Filter 進行過濾。

ICP (索引下推)技術

MySQL 5.6 推出的 ICP 技術其實就是 Index Filter 技術，只不過是因為 MySQL 分為服務層和存儲引擎層，而 Index Filter 將原本服務層做的過濾操作“下推”到存儲引擎層處理。將原來的在服務層進行的Table Filter中可以進行Index Filter的部分，在引擎層面使用 Index Filter 進行處理，不再需要回表進行 Table Filter。

這樣做的好處就是減少了加鎖的記錄數，減少了回表查詢的數量，提高了 SQL 的執行效率。

終于要到系列的最后一篇了，下一篇，我們將講解如何根據 MySQL 信息判斷死鎖和解決死鎖。請大家關注，轉發和點贊三連走起。