1. 索引優化分析

1.1 索引的概念

MySQL 官方對索引的定義為：索引（Index）是幫助MySQL 高效獲取資料的資料結構。可以得到索引的本質：索引是資料結構。可以簡單理解為排好序的快速查詢資料結構。

在資料之外，資料庫系統還維護著滿足特定查詢演算法的資料結構，這些資料結構以某種方式引用（指向）資料，這樣就可以在這些資料結構上實現高階查詢演算法。這種資料結構，就是索引。下圖就是一種可能的索引方式示例：

左邊是資料表，一共有兩列七條記錄，最左邊的是資料記錄的實體地址。為了加快Col2 的查詢，可以維護一個右邊所示的二叉查詢樹，每個節點分別包含索引鍵值和一個指向對應資料記錄實體地址的指標，這樣就可以運用二叉查詢在一定的複雜度內獲取到相應資料，從而快速的檢索出符合條件的記錄。

一般來說索引本身也很大，不可能全部儲存在記憶體中，因此索引往往以索引檔案的形式儲存的磁碟上。

1.2 優缺點

優點：

• 提高資料檢索的效率，降低資料庫的IO成本。
• 通過索引列對資料進行排序，降低資料排序的成本，降低了CPU的消耗。

缺點：

• 雖然索引大大提高了查詢速度，同時卻會降低更新表的速度，如對錶進行INSERT、UPDATE和DELETE。因為更新表時，MySQL不僅要儲存資料，還要儲存一下索引檔案每次更新添加了索引列的欄位，都會調整因為更新所帶來的鍵值變化後的索引資訊。
• 實際上索引也是一張表，該表儲存了主鍵與索引欄位，並指向實體表的記錄，所以索引列也是要佔用空間的。

2. MySQL索引的資料結構

B樹和B+樹

【小細節】

B樹就是B-tree，’ - ‘ 只是一個符號；B+樹其實是B+-tree

B樹是一棵平衡樹(AVL樹)，而平衡樹每次在進行增刪改時都會失去平衡，因此就要就要通過旋轉來保持平衡，而旋轉是非常耗時的，由此我們可以知道AVL樹適合用於插入刪除次數比較少，但查詢多的情況。

2.1 B樹

B-Tree的性質

1、定義任意非葉子結點最多隻有M個兒子，且M>2；
2、根結點的兒子數為[2, M]；
3、除根結點以外的非葉子結點的兒子數為[M/2, M]；
4、每個結點存放至少M/2-1（取上整）和至多M-1個關鍵字；（至少2個關鍵字）
5、非葉子結點的關鍵字個數=指向兒子的指標個數-1；
6、非葉子結點的關鍵字：K[1], K[2], …, K[M-1]；且K[i] < K[i+1]；
7、非葉子結點的指標：P[1], P[2], …, P[M]；其中P[1]指向關鍵字小於K[1]的子樹，P[M]指向關鍵字大於K[M-1]的子樹，其它P[i]指向關鍵字屬於(K[i-1], K[i])的子樹；
8、所有葉子結點位於同一層；

B樹結構如下圖：

【介紹】

系統從磁碟讀取資料到記憶體時是以磁碟塊（block）為基本單位的，位於同一個磁碟塊中的資料會被一次性讀取出來。

InnoDB儲存引擎中有頁（Page）的概念，頁是其磁碟管理的最小單位。InnoDB儲存引擎中預設每個頁的大小為16KB，而系統一個磁碟塊的儲存空間往往沒有這麼大，因此InnoDB每次申請磁碟空間時都會是若干地址連續磁碟塊來達到頁的大小16KB。

InnoDB在把磁碟資料讀入到記憶體時會以頁為基本單位，在查詢資料時如果一個頁中的每條資料都能有助於定位資料記錄的位置，這將會減少磁碟I/O次數，提高查詢效率。

【初始化介紹】

一顆b 樹，淺藍色的塊我們稱之為一個磁碟塊，可以看到每個磁碟塊包含幾個資料項（深藍色所示）和指標（黃色所示）；

如磁碟塊1 包含資料項17 和35，包含指標P1、P2、P3，P1 表示小於17 的磁碟塊，

P2 表示在17 和35 之間的磁碟塊，P3 表示大於35 的磁碟塊。

真實的資料存在於葉子節點即3、5、9、10、13、15、28、29、36、60、75、79、90、99。

非葉子節點只不儲存真實的資料，只儲存指引搜尋方向的資料項，如17、35 並不真實存在於資料表中。如磁碟塊1 包含資料項17 和35，包含指標P1、P2、P3

【查詢過程】

如果要查詢資料項29，那麼首先會把磁碟塊1 由磁碟載入到記憶體，此時發生一次IO，在記憶體中用二分查詢確定29在17 和35 之間，鎖定磁碟塊1 的P2 指標，記憶體時間因為非常短（相比磁碟的IO）可以忽略不計，通過磁碟塊1的P2 指標的磁碟地址把磁碟塊3 由磁碟載入到記憶體，發生第二次IO，29 在26 和30 之間，鎖定磁碟塊3 的P2 指標，通過指標載入磁碟塊8 到記憶體，發生第三次IO，同時記憶體中做二分查詢找到29，結束查詢，總計三次IO。

真實的情況是，3 層的b+樹可以表示上百萬的資料，如果上百萬的資料查詢只需要三次IO，效能提高將是巨大的，如果沒有索引，每個資料項都要發生一次IO，那麼總共需要百萬次的IO，顯然成本非常非常高。

2.2 B+Tree

B+Tree是在B-Tree基礎上的一種優化，使其更適合實現外儲存索引結構，InnoDB儲存引擎就是用B+Tree實現其索引結構。

B-Tree結構圖中可以看到每個節點中不僅包含資料的key值，還有data值。而每一個頁的儲存空間是有限的，如果data資料較大時將會導致每個節點（即一個頁）能儲存的key的數量很小，當儲存的資料量很大時同樣會導致B-Tree的深度較大，增大查詢時的磁碟I/O次數，進而影響查詢效率。在B+Tree中，所有資料記錄節點都是按照鍵值大小順序存放在同一層的葉子節點上，而非葉子節點上只儲存key值資訊，這樣可以大大加大每個節點儲存的key值數量，降低B+Tree的高度。

B+Tree相對於B-Tree有幾點不同：

1. 非葉子節點只儲存鍵值資訊。
2. 所有葉子節點之間都有一個鏈指標。
3. 資料記錄都存放在葉子節點中。

2.3 應用

B和B+樹主要用在檔案系統以及資料庫做索引，比如MySQL；

【B/B+樹效能】

在B-樹中，越靠近根節點的記錄查詢時間越快，只要找到關鍵字即可確定記錄的存在；而B+樹中每個記錄的查詢時間基本是一樣的，都需要從根節點走到葉子節點，而且在葉子節點中還要再比較關鍵字。從這個角度看B-樹的效能好像要比B+樹好，而在實際應用中卻是B+樹的效能要好些。因為B+樹的非葉子節點不存放實際的資料，這樣每個節點可容納的元素個數比B-樹多，樹高比B-樹小，這樣帶來的好處是減少磁碟訪問次數。儘管B+樹找到一個記錄所需的比較次數要比B-樹多，但是一次磁碟訪問的時間相當於成百上千次記憶體比較的時間，因此實際中B+樹的效能可能還會好些，而且B+樹的葉子節點使用指標連線在一起，方便順序遍歷（例如檢視一個目錄下的所有檔案，一個表中的所有記錄等），這也是很多資料庫和檔案系統使用B+樹的緣故。

為什麼說B+樹比B-樹更適合實際應用中作業系統的檔案索引和資料庫索引？

1、B+樹的磁碟讀寫代價更低

B+樹的內部結點並沒有指向關鍵字具體資訊的指標。因此其內部結點相對B 樹更小。如果把所有同一內部結點的關鍵字存放在同一盤塊中，那麼盤塊所能容納的關鍵字數量也越多。一次性讀入記憶體中的需要查詢的關鍵字也就越多。相對來說IO 讀寫次數也就降低了。

2、B+樹的查詢效率更加穩定

由於非終結點並不是最終指向檔案內容的結點，而只是葉子結點中關鍵字的索引。所以任何關鍵字的查詢必須走一條從根結點到葉子結點的路。所有關鍵字查詢的路徑長度相同，導致每一個數據的查詢效率相當。

3. 聚簇索引與非聚簇索引

聚簇索引並不是一種單獨的索引型別，而是一種資料儲存方式。術語‘聚簇’表示資料行和相鄰的鍵值聚簇的儲存在一起。

如下圖，左側的索引就是聚簇索引，因為資料行在磁碟的排列和索引排序保持一致。

當表中有聚簇索引時，它的資料實際上儲存在索引的葉子頁中（葉子頁中包含了行的全部資料）。而沒有聚簇索引時B+Tree葉子頁存放的是指向資料的指標。

（頁是mysql儲存引擎最小的儲存單元，InnoDB每個頁預設大小為16k）可以理解為 有聚簇索引時，資料和對應的葉子頁在同一頁中，沒有聚簇索引時，葉子頁和對應的資料不在同一頁中。

聚簇索引的好處：

• 按照聚簇索引排列順序，查詢顯示一定範圍資料的時候，由於資料都是緊密相連，資料庫不用從多個數據塊中提取資料，所以節省了大量的io 操作。
• 資料訪問更快，聚簇索引將索引和資料儲存在同一個B-Tree中，因此從舉措索引中獲取資料通常比非聚簇索引查詢更快。

聚簇索引的限制：

• 對於mysql 資料庫目前只有innodb 資料引擎支援聚簇索引，而Myisam 並不支援聚簇索引。
• 由於資料物理儲存排序方式只能有一種，所以每個Mysql 的表只能有一個聚簇索引。一般情況下就是該表的主鍵。
• 為了充分利用聚簇索引的聚簇的特性，所以innodb 表的主鍵列儘量選用有序的順序id(如AUTO_INCREMENT自增列) 而不建議用無序的id，比如uuid 這種。

【InnoDB和MyISAM儲存引擎】

InnoDB儲存引擎通過主鍵聚集資料(聚簇索引)。如果沒有定義主鍵，InnoDB會選擇一個唯一的非空索引代替。如果沒有唯一索引，InnoDB會隱式定義一個主鍵來作為聚簇索引。InnoDB 只聚集在同一個頁面中的記錄。包含相鄰健值的頁面可能相距甚遠。

MyISAM中主鍵索引和其他索引 都指向物理行 (非聚簇索引)

4. MySQL索引分類

1. 索引的分類

2. 語法

CREATE TABLE customer (
  id INT(10) UNSIGNED AUTO_INCREMENT ,
  customer_no VARCHAR(200),
  customer_name VARCHAR(200),
  
  PRIMARY KEY(id),	#設定主鍵，自動建立主鍵索引
  KEY (customer_name),	#單值索引
  UNIQUE (customer_no),	#唯一索引
  KEY (customer_no,customer_name)	#複合索引
);

單獨建單值索引：CREATE INDEX idx_customer_name ON customer(customer_name);

單獨建唯一索引：CREATE UNIQUE INDEX idx_customer_no ON customer(customer_no);

單獨建複合索引：CREATE INDEX idx_no_name ON customer(customer_no,customer_name);

5. 索引建立的時機

5.1 適合建立索引的情況

• 主鍵自動建立唯一索引；
• 頻繁作為查詢條件的欄位應該建立索引
• 查詢中與其它表關聯的欄位，外來鍵關係建立索引
• 單鍵/組合索引的選擇問題， 組合索引價效比更高
• 查詢中排序的欄位，排序欄位若通過索引去訪問將大大提高排序速度
• 查詢中統計或者分組欄位

5.2 不適合建立索引的情況

• 表記錄太少
• 經常增刪改的表或者欄位
• Where 條件裡用不到的欄位不建立索引
• 過濾性不好的不適合建索引

歡迎訪問個人部落格：http://www.itle.info/