在下面這個表T中，如果我執行 select * from T where k between 3 and 5，需要執行幾次樹的搜尋操作，會掃描多少行？

下面是這個表的初始化語句。

mysql> create table T (
ID int primary key,
k int NOT NULL DEFAULT 0, 
s varchar(16) NOT NULL DEFAULT '',
index k(k))
engine=InnoDB;

insert into T values(100,1, 'aa'),(200,2,'bb'),(300,3,'cc'),(500,5,'ee'),(600,6,'ff
 
'),(700,7,'gg');

在這個過程中，回到主鍵索引樹搜尋的過程，我們稱為回表。可以看到，這個查詢過程讀了k索引樹的3條記錄（步驟1、3和5），回表了兩次（步驟2和4）。

在這個例子中，由於查詢結果所需要的資料只在主鍵索引上有，所以不得不回表。那麼，有沒有可能經過索引優化，避免回表過程呢？

覆蓋索引

如果執行的語句是select ID from T where k between 3 and 5，這時只需要查ID的值，而ID的值已經在k索引樹上了，因此可以直接提供查詢結果，不需要回表。也就是說，在這個查詢裡面，索引k已經“覆蓋了”我們的查詢需求，我們稱為覆蓋索引。

由於覆蓋索引可以減少樹的搜尋次數，顯著提升查詢效能，所以使用覆蓋索引是一個常用的效能優化手段。

基於上面覆蓋索引的說明，我們來討論一個問題：在一個市民資訊表上，是否有必要將身份證號和名字建立聯合索引？

假設這個市民表的定義是這樣的：

CREATE TABLE `tuser` (
  `id` int(11) NOT NULL,
  `id_card` varchar(32) DEFAULT NULL,
  `name` varchar(32) DEFAULT NULL,
  `age` int(11) DEFAULT NULL,
  `ismale` tinyint(1) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `id_card` (`id_card`),
  
 
KEY `name_age` (`name`,`age`)
) ENGINE=InnoDB

我們知道，身份證號是市民的唯一標識。也就是說，如果有根據身份證號查詢市民資訊的需求，我們只要在身份證號欄位上建立索引就夠了。而再建立一個（身份證號、姓名）的聯合索引，是不是浪費空間？

如果現在有一個高頻請求，要根據市民的身份證號查詢他的姓名，這個聯合索引就有意義了。它可以在這個高頻請求上用到覆蓋索引，不再需要回表查整行記錄，減少語句的執行時間。

當然，索引欄位的維護總是有代價的。因此，在建立冗餘索引來支援覆蓋索引時就需要權衡考慮了。這正是業務DBA，或者稱為業務資料架構師的工作。

最左字首原則

看到這裡你一定有一個疑問，如果為每一種查詢都設計一個索引，索引是不是太多了。如果我現在要按照市民的身份證號去查他的家庭地址呢？雖然這個查詢需求在業務中出現的概率不高，但總不能讓它走全表掃描吧？反過來說，單獨為一個不頻繁的請求建立一個（身份證號，地址）的索引又感覺有點浪費。應該怎麼做呢？

這裡，我先和你說結論吧。B+樹這種索引結構，可以利用索引的“最左字首”，來定位記錄。

為了直觀地說明這個概念，我們用（name，age）這個聯合索引來分析。

可以看到，索引項是按照索引定義裡面出現的欄位順序排序的。

當你的邏輯需求是查到所有名字是“張三”的人時，可以快速定位到ID4，然後向後遍歷得到所有需要的結果。

如果你要查的是所有名字第一個字是“張”的人，你的SQL語句的條件是"where name like ‘張%’"。這時，你也能夠用上這個索引，查詢到第一個符合條件的記錄是ID3，然後向後遍歷，直到不滿足條件為止。

可以看到，不只是索引的全部定義，只要滿足最左字首，就可以利用索引來加速檢索。這個最左字首可以是聯合索引的最左N個欄位，也可以是字串索引的最左M個字元。

基於上面對最左字首索引的說明，我們來討論一個問題：在建立聯合索引的時候，如何安排索引內的欄位順序。

這裡我們的評估標準是，索引的複用能力。因為可以支援最左字首，所以當已經有了(a,b)這個聯合索引後，一般就不需要單獨在a上建立索引了。因此，第一原則是，如果通過調整順序，可以少維護一個索引，那麼這個順序往往就是需要優先考慮採用的。

這裡我們的評估標準是，索引的複用能力。因為可以支援最左字首，所以當已經有了(a,b)這個聯合索引後，一般就不需要單獨在a上建立索引了。因此，第一原則是，如果通過調整順序，可以少維護一個索引，那麼這個順序往往就是需要優先考慮採用的。

所以現在你知道了，這段開頭的問題裡，我們要為高頻請求建立(身份證號，姓名）這個聯合索引，並用這個索引支援“根據身份證號查詢地址”的需求。

那麼，如果既有聯合查詢，又有基於a、b各自的查詢呢？查詢條件裡面只有b的語句，是無法使用(a,b)這個聯合索引的，這時候你不得不維護另外一個索引，也就是說你需要同時維護(a,b)、(b) 這兩個索引。

這時候，我們要考慮的原則就是空間了。比如上面這個市民表的情況，name欄位是比age欄位大的 ，那我就建議你建立一個（name,age)的聯合索引和一個(age)的單欄位索引。

索引下推

上一段我們說到滿足最左字首原則的時候，最左字首可以用於在索引中定位記錄。這時，你可能要問，那些不符合最左字首的部分，會怎麼樣呢？

我們還是以市民表的聯合索引（name, age）為例。如果現在有一個需求：檢索出表中“名字第一個字是張，而且年齡是10歲的所有男孩”。那麼，SQL語句是這麼寫的：

mysql> select * from tuser where name like '張%' and age=10 and ismale=1;

你已經知道了字首索引規則，所以這個語句在搜尋索引樹的時候，只能用 “張”，找到第一個滿足條件的記錄ID3。當然，這還不錯，總比全表掃描要好。

然後呢？

當然是判斷其他條件是否滿足。

在MySQL 5.6之前，只能從ID3開始一個個回表。到主鍵索引上找出資料行，再對比欄位值。

而MySQL 5.6 引入的索引下推優化（index condition pushdown)， 可以在索引遍歷過程中，對索引中包含的欄位先做判斷，直接過濾掉不滿足條件的記錄，減少回表次數。

圖3和圖4，是這兩個過程的執行流程圖。

在圖3和4這兩個圖裡面，每一個虛線箭頭表示回表一次。

圖3中，在(name,age)索引裡面我特意去掉了age的值，這個過程InnoDB並不會去看age的值，只是按順序把“name第一個字是’張’”的記錄一條條取出來回表。因此，需要回表4次。

圖4跟圖3的區別是，InnoDB在(name,age)索引內部就判斷了age是否等於10，對於不等於10的記錄，直接判斷並跳過。在我們的這個例子中，只需要對ID4、ID5這兩條記錄回表取資料判斷，就只需要回表2次。

實際上主鍵索引也是可以使用多個欄位的。DBA小呂在入職新公司的時候，就發現自己接手維護的庫裡面，有這麼一個表，表結構定義類似這樣的：

CREATE TABLE `geek` (
  `a` int(11) NOT NULL,
  `b` int(11) NOT NULL,
  `c` int(11) NOT NULL,
  `d` int(11) NOT NULL,
  PRIMARY KEY (`a`,`b`),
  KEY `c` (`c`),
  KEY `ca` (`c`,`a`),
  KEY `cb` (`c`,`b`)
) ENGINE=InnoDB;