參考文章：https://time.geekbang.org/column/article/68319
目錄
索引的出現其實就是爲了提高數據查詢的效率，就像書的目錄一樣。
索引的常見模型
1、哈希表
哈希表是一種以鍵 - 值（key-value）存儲數據的結構，只要輸入待查找的值即 key，就可以找到其對應的值即 Value。不可避免地，多個 key 值經過哈希函數的換算，會出現同一個值的情況。處理這種情況的一種方法是，拉出一個鏈表。
哈希表這種結構適用於只有等值查詢的場景，比如 Memcached 及其他一些 NoSQL 引擎。
2、有序數組
假設身份證號沒有重複，這個數組就是按照身份證號遞增的順序保存的。在查找時可使用二分查找
如果僅僅看查詢效率，有序數組就是最好的數據結構了。但是，在需要更新數據的時候就麻煩了，你往中間插入一個記錄就必須得挪動後面所有的記錄，成本太高。（查詢效率高，更新效率低）。有序數組索引只適用於靜態存儲引擎
有序數組在等值查詢和範圍查詢場景中的性能就都非常優秀。
3、搜索樹
二叉搜索樹的特點是：每個節點的左兒子小於父節點，父節點又小於右兒子
爲了維持 O(log(N)) 的查詢複雜度，你就需要保持這棵樹是平衡二叉樹。爲了做這個保證，更新的時間複雜度也是 O(log(N))。
樹可以有二叉，也可以有多叉。多叉樹就是每個節點有多個兒子，兒子之間的大小保證從左到右遞增。二叉樹是搜索效率最高的，但是實際上大多數的數據庫存儲卻並不使用二叉樹。其原因是，索引不止存在內存中，還要寫到磁盤上。
你可以想象一下一棵 100 萬節點的平衡二叉樹，樹高 20。一次查詢可能需要訪問 20 個數據塊。在機械硬盤時代，從磁盤隨機讀一個數據塊需要 10 ms 左右的尋址時間。也就是說，對於一個 100 萬行的表，如果使用二叉樹來存儲，單獨訪問一個行可能需要 20 個 10 ms 的時間，這個查詢可真夠慢的。
爲了讓一個查詢儘量少地讀磁盤，就必須讓查詢過程訪問儘量少的數據塊。那麼，我們就不應該使用二叉樹，而是要使用“N 叉”樹。這裏，“N 叉”樹中的“N”取決於數據塊的大小。
InnoDB 的索引模型
在 MySQL 中，索引是在存儲引擎層實現的，所以並沒有統一的索引標準，即不同存儲引擎的索引的工作方式並不一樣。而即使多個存儲引擎支持同一種類型的索引，其底層的實現也可能不同。
在 InnoDB 中，表都是根據主鍵順序以索引的形式存放的，這種存儲方式的表稱爲索引組織表。
每一個索引在 InnoDB 裏面對應一棵 B+ 樹。
假設，我們有一個主鍵列爲 ID 的表，表中有字段 k，並且在 k 上有索引：
create table T(
id int primary key,
k int not null,
name varchar(16),
index (k))engine=InnoDB;
根據葉子節點的內容，索引類型分爲主鍵索引和非主鍵索引。
主鍵索引的葉子節點存的是整行數據。在 InnoDB 裏，主鍵索引也被稱爲聚簇索引（clustered index）。
非主鍵索引的葉子節點內容是主鍵的值。在 InnoDB 裏，非主鍵索引也被稱爲二級索引（secondary index）。
索引維護
B+ 樹爲了維護索引有序性，在插入新值的時候需要做必要的維護
頁分裂：數據頁已經滿了，根據 B+ 樹的算法，這時候需要申請一個新的數據頁，然後挪動部分數據過去。影響性能和數據頁的利用率
頁合併：當相鄰兩個頁由於刪除了數據，利用率很低之後，會將數據頁做合併
**哪些場景下應該使用自增主鍵，而哪些場景下不應該？
1、適合用自增主鍵
（1）從性能的角度
自增主鍵的插入數據模式，正符合了我們前面提到的遞增插入的場景。每次插入一條新記錄，都是追加操作，都不涉及到挪動其他記錄，也不會觸發葉子節點的分裂。而有業務邏輯的字段做主鍵，則往往不容易保證有序插入，這樣寫數據成本相對較高。
（2）從存儲空間的角度
假設你的表中確實有一個唯一字段，比如字符串類型的身份證號，那應該用身份證號做主鍵，還是用自增字段做主鍵呢？
由於每個非主鍵索引的葉子節點上都是主鍵的值。如果用身份證號做主鍵，那麼每個二級索引的葉子節點佔用約 20 個字節，而如果用整型做主鍵，則只要 4 個字節，如果是長整型（bigint）則是 8 個字節。主鍵長度越小，普通索引的葉子節點就越小，普通索引佔用的空間也就越小。
從性能和存儲空間方面考量，自增主鍵往往是更合理的選擇。
2、適合業務字段直接做主鍵
（1）只有一個索引；
（2）該索引必須是唯一索引。
這就是典型的 KV 場景。由於沒有其他索引，所以也就不用考慮其他索引的葉子節點大小的問題。這時候我們就要優先考慮上一段提到的“儘量使用主鍵查詢”原則，直接將這個索引設置爲主鍵，可以避免每次查詢需要搜索兩棵樹。
-----------------------------------我是快樂且好學的分割線-----------------------------------
思考：
對於上面例子中的 InnoDB 表 T，如果你要重建索引 k，你的兩個 SQL 語句可以這麼寫：
如果你要重建主鍵索引，也可以這麼寫：
對於上面這兩個重建索引的作法，說出你的理解。如果有不合適的，爲什麼，更好的方法是什麼？
（通過兩個 alter 語句重建索引 k，以及通過兩個 alter 語句重建主鍵索引是否合理。）
答：建索引 k 的做法是合理的，可以達到省空間的目的。但是，重建主鍵的過程不合理。不論是刪除主鍵還是創建主鍵，都會將整個表重建。所以連着執行這兩個語句的話，第一個語句就白做了。
這兩個語句，你可以用這個語句代替 ： alter table T engine=InnoDB。
-----------------------------------我是快樂且好學的分割線-----------------------------------
有價值的問題：
1、select ＊from table where id＝xx和select id from table where id＝xx的效率是一樣的嗎？（id是主鍵）
這兩個語句是都不用回表了，在“查找行”這個邏輯上是一樣的，但是select *要讀和拷貝更多列到server,還要發送更多列給客戶端，所以還是select id更快的。
2、沒有主鍵的表，innodb會給默認創建一個Rowid做主鍵
3、之前看過一遍文章，一直有疑惑：一個innoDB引擎的表，數據量非常大，根據二級索引搜索會比主鍵搜索快，文章闡述的原因是主鍵索引和數據行在一起，非常大搜索慢，我的疑惑是：通過普通索引找到主鍵ID後，同樣要跑一邊主鍵索引呀？
4、索引只能定位到page，page內部怎麼去定位行數據？
內部有個有序數組，二分法
5、innodb B+樹主鍵索引的葉子節點存的是什麼？
B+樹的葉子節點是page （頁），一個頁裏面可以存多個行
6、如果記錄表中 R1~R5 的 (ID,k) 值分別爲 (100,1)、(200,1)、(300,1)、(500,1) 和 (600,1)，那麼非主鍵索引上有5個值，分別是（1，100），（1，200）... （1，600）
7、現在一般自增索引都設置爲bigint，這點這麼看？
特別合理，因爲現在很多業務插入數據很兇殘，容易超過int 上限，實際上是建議設置bigint unsigned
8、爲什麼要重建索引
索引可能因爲刪除，或者頁分裂等原因，導致數據頁有空洞，重建索引的過程會創建一個新的索引，把數據按順序插入，這樣頁面的利用率最高，也就是索引更緊湊、更省空間。
-----------------------------------我是快樂且好學的分割線-----------------------------------
總結：
1.索引的作用：提高數據查詢效率
2.常見索引模型：哈希表、有序數組、搜索樹
3.哈希表：鍵 - 值(key - value)。
4.哈希思路：把值放在數組裏，用一個哈希函數把key換算成一個確定的位置，然後把value放在數組的這個位置
5.哈希衝突的處理辦法：鏈表
6.哈希表適用場景：只有等值查詢的場景
7.有序數組：按順序存儲。查詢用二分法就可以快速查詢，時間複雜度是：O(log(N))
8.有序數組查詢效率高，更新效率低
9.有序數組的適用場景：靜態存儲引擎。
10.二叉搜索樹：每個節點的左兒子小於父節點，父節點又小於右兒子
11.二叉搜索樹：查詢時間複雜度O(log(N))，更新時間複雜度O(log(N))
12.數據庫存儲大多不適用二叉樹，因爲樹高過高，會適用N叉樹
13.InnoDB中的索引模型：B+Tree
14.索引類型：主鍵索引、非主鍵索引
主鍵索引的葉子節點存的是整行的數據(聚簇索引)，非主鍵索引的葉子節點內容是主鍵的值(二級索引)
15.主鍵索引和普通索引的區別：主鍵索引只要搜索ID這個B+Tree即可拿到數據。普通索引先搜索索引拿到主鍵值，再到主鍵索引樹搜索一次(回表)
16.一個數據頁滿了，按照B+Tree算法，新增加一個數據頁，叫做頁分裂，會導致性能下降。空間利用率降低大概50%。當相鄰的兩個數據頁利用率很低的時候會做數據頁合併，合併的過程是分裂過程的逆過程。
17.從性能和存儲空間方面考量，自增主鍵往往是更合理的選擇。
