爲何用了索引以後，查詢就會變快？

相信不少程序員朋友對數據的索引並不陌生，最多見的索引是 B+ Tree 索引，索引能夠加快數據庫的檢索速度，可是會下降新增、修改、刪除操做的速度，一些錯誤的寫法會致使索引失效等等。

可是若是被問到，爲何用了索引以後，查詢就會變快？B+ Tree 索引的原理是什麼？這時候不少人可能就不知道了，今天我就以 MySQL 的 InnoDB 引擎爲例，講一講 B+ Tree 索引的原理。

索引的基礎知識

MySQL 的基本存儲結構是頁，大概就是這個樣子的：

innoDB 頁結構

在這裏，咱們須要瞭解如下幾點（很是重要）：

• 當咱們用 MySQL 的 InnoDB 引擎建立表，有且只能有一個主鍵；若是咱們沒有顯示地指定之間，那麼MySQL 會自動生成一個隱含字段做爲主鍵；
• 彙集索引：以主鍵建立的索引；彙集索引的葉子節點存儲的是表中的數據；
• 非彙集索引：非主鍵建立的索引；非彙集索引在葉子節點存儲的是主鍵和索引列；使用非彙集索引查詢數據，會查詢到葉子上的主鍵，再根據主鍵查到數據（這個過程叫作回表）。

頁和頁之間、頁和數據之間的關係

咱們以彙集索引作講解，頁和頁之間、以及頁和數據之間的關係是這樣的：

頁和頁的關係

• 數據頁和數據頁之間，組成一個雙向鏈表；
• 每一個數據頁中的記錄，是一個單向鏈表；
• 每一個數據頁都根據內部的記錄生成一個頁目錄（Page directory），若是是主鍵的話，能夠在頁目錄中使用二分法快速定位；
• 若是咱們根據一個非主鍵、非索引列進行查詢，那麼須要遍歷雙向鏈表，找到所在的頁；再遍歷頁內的單向鏈表；若是表內數據很大的話，這樣的查詢就會很慢。

B+ Tree 索引的原理

先讓咱們看看 B+ Tree 索引大概是什麼樣子（以彙集/主鍵索引爲例）：

B+Tree索引

• 假如這時候咱們要查詢 id = 16 的數據：
• 查詢頁-1，找到頁-2 存儲的是小於 30 的數據；
• 查詢頁-2，找到頁-5 存儲的是 10~20 的數據；
• 查詢頁-5，找到 id = 16 的數據。

很顯然，沒有用索引的時候，須要遍歷雙向鏈表來定位對應的頁，而有了索引，則能夠經過一層層「目錄」定位到對應的頁上。

爲何 B+ Tree 索引會下降新增、修改、刪除的速度

• B+ Tree 是一顆平衡樹，若是對這顆樹新增、修改、刪除的話，會破壞它的原有結構；
• 咱們在作數據新增、修改、刪除的時候，須要花額外的時間去維護索引；
• 正由於這些額外的開銷，致使索引會下降新增、修改、刪除的速度。

如今你是否理解了 B+ Tree 索引的原理？

最後再留一個思考題：爲何官方建議使用自增加主鍵做爲索引？你們能夠在留言中寫下你的答案。

會點代碼的大叔 | 文【原創】

---

會點代碼的大叔