文章目錄
索引與算法
索引太多，應用程序的性能可能會受到影響，索引太少，對查詢性能可能又會產生影響。
如果知道數據的使用，從一開始就應該添加索引。如何後期添加索引，需要監控大量的SQL語句進而從中找到問題，這個步驟所需的時間肯定是遠遠大於初始添加索引所要的時間。
一、InnoDB存儲引擎索引概述
幾種常見的索引：
- B+樹索引
- 全文索引
- 哈希索引
InnoDB支持的哈希索引是自適應的，InnoDB存儲引擎會根據表的使用情況自動爲表生成哈希索引
B+樹索引的構造類似於二叉樹，根據鍵值快速找到數據。
B+樹索引並不能找到給定一個鍵值的具體行，B+樹索引能找到的只是被查找數據行所在的頁，然後數據庫將頁讀入到內存，再在內存中進行查找，最後得到要查找的數據
二、數據結構與算法
1、二分查找法(找到頁之後，具體哪條記錄是通過二分查找得到的)
數據必須有序，根據前面的學習，每頁Page Directory中的槽是按照主鍵的順序存放的，對於某一條具體記錄的查詢是通過Page Directory進行二分查找得到的。
2、二叉查找樹和平衡二叉樹
B+樹是由二叉查找樹，再由平衡二叉樹，B樹演變而來。
平衡二叉樹首先是一棵二叉查找樹，雖然平衡二叉樹的查找效率很高，但是維護可能需要一次旋轉或者多次。
三、B+樹
B+樹由B樹和索引順序訪問方法演化而來。
B+樹是爲磁盤或其他存儲輔助設備設計的一種平衡查找樹。在B+樹中，所有記錄節點都是按照鍵值的大小順序存放在同一層的葉子節點上的，由各個葉子節點指針進行連接。
1、B+樹的插入操作(可能需要拆頁)
B+樹插入必須保證插入後葉子節點中的記錄既然是有序的。
插入要考慮以下三種情況：
B+樹總是會保證平衡，但是爲了保證平衡，新插入的鍵值可能需要做大量的拆分頁操作。
由於B+樹的結構主要用於磁盤，頁的拆分意味着磁盤的操作，所以應該在可能的情況下儘量減少頁的拆分操作。
2、B+樹的刪除操作(填充因子最小50%)
B+樹通過填充因子來控制樹的刪除操作，50%樹填充因子可設的最小值。
下面是刪除的三種情況，與插入不同的是，刪除根據填充因子的變化來衡量。
四、B+樹索引
B+樹的高度一般都在2-4層，這也就是說查找某一鍵值的記錄時，最多需要2到4次IO，這倒不錯。因爲當前一般的機械磁盤每秒至少可以做100次IO，2-4次的IO的意思是查詢時間只需0.02-0.04秒/
B+樹索引分類(其他的索引比如唯一索引等都屬於B+樹索引)：
- 聚集索引(存放一整行數據)
- 輔助索引
1、聚集索引(邏輯上連續，物理上不連續，每個表只有一個)
聚集索引就是按照每張表的主鍵構造一棵B+樹，同時葉子節點存放的是整張表的行記錄數據，也將聚集索引的葉子節點稱爲數據頁，數據頁通過雙向鏈表進行鏈接。
由於實際的數據頁只能按照一棵B+樹進行排序，因此只能擁有一個聚集索引，一般查詢優化器傾向於使用聚集索引，因爲可以在葉子節點直接找到數據，由於定義了數據的邏輯順序，聚集索引能很快的訪問針對範圍值的查詢。
數據頁存放的是完整的每行的記錄，而在非數據頁的索引頁中，存放的僅僅是鍵值及指向數據頁的偏移量，而不是完整的行記錄
聚集索引邏輯上連續，物理上不連續，通過雙向鏈表鏈接
聚集索引還有一個好處是排序查找和範圍查找非常快。
可以看到雖然查詢語句使用了Order by進行排序，但是實際上並沒有所謂的filesort操作，這就是因爲聚集索引的特點。
範圍查找：
通過葉子節點的上一層中間節點就可以得到頁的範圍，之後直接讀取數據頁即可。
2、輔助索引
對於輔助索引即非聚集索引，葉子節點並不包含行記錄的全部數據，葉子節點除了包含鍵值之外，每個葉子節點中的索引行中還包含了一個書籤，該書籤用來告訴InnoDB存儲引擎哪裏可以找到與索引相對應的行數據。由於InnoDB存儲引擎表是索引組織表，因此InnoDB存儲引擎的輔助索引的書籤就是相應的行數據的聚集索引鍵(主鍵？)
當通過輔助索引來查找數據的時候，InnoDB存儲引擎會遍歷輔助索引並通過葉級別的指針指向主鍵索引的主鍵，然後在通過主鍵索引來找到完整的行記錄。