【版權申明】未經博主同意，謝絕轉載！（請尊重原創，博主保留追究權）
https://blog.csdn.net/qq_36000403/article/details/91355358
出自【zzf__的博客】
一、索引的作用
提高數據查詢效率
二、索引模型
1.哈希表
實現思路:把值放在數組裏，用一個哈希函數把key換算成一個確定的位置，然後把value放在數組的這個位置
哈希衝突的處理辦法：鏈表
優點:由於根據key算出來的哈希值在數組中對應的位置是無序的，所以可以很快就能添加新的值進哈希表中
缺點:正是由於key算出來的哈希值在數組中對應的位置是無序的，所以哈希索引做區間查詢的速度是很慢的
適用場景：只有等值查詢的場景，比如 Memcached 及其他一些 NoSQL 引擎。
2. 有序數組
優點:等值查詢(查詢用二分法就可以快速查詢，時間複雜度是O(log(N))) 和 區間查詢都非常優秀
缺點:更新效率低,插入一個數據，需要挪動數據。
適用場景：靜態存儲引擎，比如你要保存的是 2017 年某個城市的所有人口信息，這類不會再修改的數據。
3. 搜索樹
1.二叉搜索樹
定義：每個節點的左兒子小於父節點，父節點又小於右兒子
優點:查詢效率高，時間複雜度O(log(N))。
爲了維持 O(log(N)) 的查詢複雜度，你就需要保持這棵樹是平衡二叉樹。爲了做這個保證，更新的時間複雜度也是 O(log(N))。
2.爲什麼大多數的數據庫存儲卻並不使用二叉樹
因爲索引不止存在內存中，還要寫到磁盤上。
你可以想象一下一棵 100 萬節點的平衡二叉樹，樹高 20。一次查詢可能需要訪問 20 個數據塊。在機械硬盤時代，從磁盤隨機讀一個數據塊需要 10 ms 左右的尋址時間。也就是說，對於一個 100 萬行的表，如果使用二叉樹來存儲，單獨訪問一個行可能需要 20 個 10 ms 的時間，這個查詢可真夠慢的。
爲了讓一個查詢儘量少地讀磁盤，就必須讓查詢過程訪問儘量少的數據塊。那麼，我們就不應該使用二叉樹，而是要使用“N 叉”樹。這裏，“N 叉”樹中的“N”取決於數據塊的大小。
以 InnoDB 的一個整數字段索引爲例，這個 N 差不多是 1200。這棵樹高是 4 的時候，就可以存 1200 的 3 次方個值，這已經 17 億了。考慮到樹根的數據塊總是在內存中的，一個 10 億行的表上一個整數字段的索引，查找一個值最多只需要訪問 3 次磁盤。其實，樹的第二層也有很大概率在內存中，那麼訪問磁盤的平均次數就更少了。
N 叉樹由於在讀寫上的性能優點，以及適配磁盤的訪問模式，已經被廣泛應用在數據庫引擎中了。
B+ 樹能夠很好地配合磁盤的讀寫特性，減少單次查詢的磁盤訪問次數。
三、 InnoDB的索引模型
InnoDB 使用了 B+ 樹索引模型，所以數據都是存儲在 B+ 樹中的，每一個索引在 InnoDB 裏面對應一棵 B+ 樹。
索引類型
主鍵索引
主鍵索引的葉子節點存的是整行數據。在 InnoDB 裏，主鍵索引也被稱爲聚簇索引（clustered index）。
非主鍵索引
非主鍵索引的葉子節點內容是主鍵的值。在 InnoDB 裏，非主鍵索引也被稱爲二級索引（secondary index）。
基於主鍵索引和普通索引的查詢有什麼區別？
如果語句是 select * from T where ID=500，即主鍵查詢方式，則只需要搜索 ID 這棵 B+ 樹；
如果語句是 select * from T where k=5，即普通索引查詢方式，則需要先搜索 k 索引樹，得到 ID 的值爲 500，再到 ID 索引樹搜索一次。這個過程稱爲回表。
總結:基於非主鍵索引的查詢需要多掃描一棵索引樹。因此，我們在應用中應該儘量使用主鍵查詢。
索引維護
爲什麼需要維護索引?
B+ 樹爲了維護索引有序性，在插入新值的時候需要做必要的維護。
弊端:
挪動後面的數據:
以上面這個圖爲例，如果插入新的行 ID 值爲 700，則只需要在 R5 的記錄後面插入一個新記錄。如果新插入的 ID 值爲 400，就相對麻煩了，需要邏輯上挪動後面的數據，空出位置。
頁分裂:
而更糟的情況是，如果 R5 所在的數據頁已經滿了，根據 B+ 樹的算法，這時候需要申請一個新的數據頁，然後挪動部分數據過去。這個過程稱爲頁分裂。在這種情況下，性能自然會受影響。
影響數據頁的利用率:
除了性能外，頁分裂操作還影響數據頁的利用率。原本放在一個頁的數據，現在分到兩個頁中，整體空間利用率降低大約 50%。
當然有分裂就有合併。當相鄰兩個頁由於刪除了數據，利用率很低之後，會將數據頁做合併。合併的過程，可以認爲是分裂過程的逆過程。
四、哪些場景下應該使用自增主鍵，而哪些場景下不應該
自增主鍵定義
自增主鍵是指自增列上定義的主鍵，在建表語句中一般是這麼定義的： NOT NULL PRIMARY KEY AUTO_INCREMENT。
性能角度分析
使用自增主鍵優點:
每次插入一條新記錄，都是追加操作，都不涉及到挪動其他記錄，也不會觸發葉子節點的分裂。
而有業務邏輯的字段做主鍵，則往往不容易保證有序插入，這樣寫數據成本相對較高。
存儲空間角度分析
由於每個非主鍵索引的葉子節點上都是主鍵的值。
主鍵長度越小，普通索引的葉子節點就越小，普通索引佔用的空間也就越小
總結:從性能和存儲空間方面考量，自增主鍵往往是更合理的選擇。
業務字段做主鍵的場景
有沒有什麼場景適合用業務字段直接做主鍵的呢？還是有的。比如，有些業務的場景需求是這樣的：
只有一個索引；
該索引必須是唯一索引。
你一定看出來了，這就是典型的 KV 場景。
由於沒有其他索引，所以也就不用考慮其他索引的葉子節點大小的問題。
這時候我們就要優先考慮上一段提到的“儘量使用主鍵查詢”原則，直接將這個索引設置爲主鍵，可以避免每次查詢需要搜索兩棵樹。
4.總結
你心裏要有個概念，數據庫底層存儲的核心就是基於這些數據模型的。每碰到一個新數據庫，我們需要先關注它的數據模型，這樣才能從理論上分析出這個數據庫的適用場景。
12.數據庫存儲大多不適用二叉樹，因爲樹高過高，會適用N叉樹
13.InnoDB中的索引模型：B+Tree
14.索引類型：主鍵索引、非主鍵索引
主鍵索引的葉子節點存的是整行的數據(聚簇索引)，非主鍵索引的葉子節點內容是主鍵的值(二級索引)
15.主鍵索引和普通索引的區別：主鍵索引只要搜索ID這個B+Tree即可拿到數據。普通索引先搜索索引拿到主鍵值，再到主鍵索引樹搜索一次(回表)
16.一個數據頁滿了，按照B+Tree算法，新增加一個數據頁，叫做頁分裂，會導致性能下降。空間利用率降低大概50%。當相鄰的兩個數據頁利用率很低的時候會做數據頁合併，合併的過程是分裂過程的逆過程。
17.從性能和存儲空間方面考量，自增主鍵往往是更合理的選擇。