索引簡介

索引簡介

1、索引是什么

索引是個什么東東？

1. MySQL官方對索引的定義為：索引(Index)是幫助MySQL高效獲取數據的數據結構。可以得到索引的本質：索引是數據結構
2. 你可以簡單理解為"排好序的快速查找數據結構"，即索引 = 排序 + 查找
3. 一般來說索引本身占用內存空間也很大，不可能全部存儲在內存中，因此索引往往以文件形式存儲在硬盤上
4. 我們平時所說的索引，如果沒有特別指明，都是指B樹(多路搜索樹，並不一定是二叉樹)結構組織的索引。
5. 聚集索引，次要索引，覆蓋索引，復合索引，前綴索引，唯一索引默認都是使用B+樹索引，統稱索引。當然，除了B+樹這種類型的索引之外，還有哈希索引(hash index)等。

2、索引原理

將索引理解為"排好序的快速查找數據結構"

1. 在數據之外，數據庫系統還維護着滿足特定查找算法的數據結構，這些數據結構以某種方式引用（指向）數據，這樣就可以在這些數據結構上實現高級查找算法。這種數據結構，就是索引。
2. 下圖就是一種可能的索引方式示例：
   • 左邊是數據表，一共有兩列七條記錄，最左邊的十六進制數字是數據記錄的物理地址
   • 為了加快col2的查找，可以維護一個右邊所示的二叉查找樹，每個節點分別包含索引鍵值和一個指向對應數據記錄物理地址的指針，這樣就可以運用二叉查找在一定的復雜度內獲取到相應數據，從而快速的檢索出符合條件的記錄。

image-20200803222848380

3、索引優劣勢

索引的優勢

1. 類似大學圖書館的書目索引，提高數據檢索效率，降低數據庫的IO成本
2. 通過索引列對數據進行排序，降低數據排序成本，降低了CPU的消耗

索引的劣勢

1. 實際上索引也是一張表，該表保存了主鍵和索引字段，並指向實體表的記錄，所以索引列也是要占用空間的
2. 雖然索引大大提高了查詢速度，同時卻會降低更新表的速度，如果對表INSERT，UPDATE和DELETE。因為更新表時，MySQL不僅要不存數據，還要保存一下索引文件每次更新添加了索引列的字段，都會調整因為更新所帶來的鍵值變化后的索引信息
3. 索引只是提高效率的一個因素，如果你的MySQL有大數據量的表，就需要花時間研究建立優秀的索引，或優化查詢語句

4、MySQL 索引分類

mysql 索引分類

參考資料：https://www.cnblogs.com/luyucheng/p/6289714.html

1. 普通索引：是最基本的索引，它沒有任何限制，即一個索引只包含單個列，一個表可以有多個單列索引；建議一張表索引不要超過5個，優先考慮復合索引
2. 唯一索引：與前面的普通索引類似，不同的就是：索引列的值必須唯一，但允許有空值。如果是組合索引，則列值的組合必須唯一
3. 主鍵索引：是一種特殊的唯一索引，一個表只能有一個主鍵，不允許有空值。一般是在建表的時候同時創建主鍵索引：
4. 復合索引：指多個字段上創建的索引，只有在查詢條件中使用了創建索引時的第一個字段，索引才會被使用。使用組合索引時遵循最左前綴集合
5. 全文索引：主要用來查找文本中的關鍵字，而不是直接與索引中的值相比較。fulltext索引跟其它索引大不相同，它更像是一個搜索引擎，而不是簡單的where語句的參數匹配

5、MySQL 索引語法

建立索引的 SQL 語句

1. 創建索引：

   • 如果是CHAR和VARCHAR類型，length可以小於字段實際長度；
   • 如果是BLOB和TEXT類型，必須指定length。

   CREATE [UNIQUE] INDEX  indexName ON mytable(columnname(length));
   ' or '
   ALTER mytable ADD [UNIQUE]  INDEX [indexName] ON(columnname(length));

2. 刪除索引

   DROP INDEX [indexName] ON mytable;

3. 查看索引（\G表示將查詢到的橫向表格縱向輸出，方便閱讀）

   SHOW INDEX FROM table_name\G

---

使用 ALTER 命令，有四種方式來添加數據表的索引：

1. ALTER TABLE tbl_name ADD PRIMARY KEY(column_list)：該語句添加一個主鍵，這意味着索引值必須是唯一的，且不能為NULL。
2. ALTER TABLE tbl_name ADD UNIQUE index_name(column_list)：這條語句創建索引的值必須是唯一的（除了NULL外，NULL可能會出現多次）。
3. ALTER TABLE tbl_name ADD INDEX index_name(column_list)：.添加普通索引，索引值可出現多次。
4. ALTER TABLE tbl_name ADD FULLTEXT index_name(column_list)：該語句指定了索引為FULLTEXT，用於全文索引。

---

帶你看看 mysql 索引：Index_type 為 BTREE

mysql> show index from tbl_emp;
+---------+------------+------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| Table   | Non_unique | Key_name   | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |
+---------+------------+------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| tbl_emp |          0 | PRIMARY    |            1 | id          | A         |           8 |     NULL | NULL   |      | BTREE      |         |               |
| tbl_emp |          1 | fk_dept_Id |            1 | deptId      | A         |           8 |     NULL | NULL   | YES  | BTREE      |         |               |
+---------+------------+------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
2 rows in set (0.00 sec)

6、MySQL 索引結構

6.1、Btree 索引

Btree 索引搜索過程

【初始化介紹】

1. 一顆 b 樹， 淺藍色的塊我們稱之為一個磁盤塊， 可以看到每個磁盤塊包含幾個數據項（深藍色所示） 和指針（黃色所示）
2. 如磁盤塊 1 包含數據項 17 和 35， 包含指針 P1、 P2、 P3
3. P1 表示小於 17 的磁盤塊， P2 表示在 17 和 35 之間的磁盤塊， P3 表示大於 35 的磁盤塊
4. 真實的數據存在於葉子節點和非葉子節點中

【查找過程】

1. 如果要查找數據項 29， 那么首先會把磁盤塊 1 由磁盤加載到內存， 此時發生一次 IO， 在內存中用二分查找確定 29在 17 和 35 之間， 鎖定磁盤塊 1 的 P2 指針， 內存時間因為非常短（相比磁盤的 IO） 可以忽略不計
2. 通過磁盤塊 1的 P2 指針的磁盤地址把磁盤塊 3 由磁盤加載到內存， 發生第二次 IO， 29 在 26 和 30 之間， 鎖定磁盤塊 3 的 P2 指針
3. 通過指針加載磁盤塊 8 到內存， 發生第三次 IO， 同時內存中做二分查找找到 29， 結束查詢， 總計三次 IO。

image-20200804093236612

6.2、B+tree 索引

B+tree 索引搜索過程

【B+Tree 與 BTree 的區別】

B-樹的關鍵字（數據項）和記錄是放在一起的； B+樹的非葉子節點中只有關鍵字和指向下一個節點的索引， 記錄只放在葉子節點中。

【B+Tree 與 BTree 的查找過程】

1. 在 B 樹中， 越靠近根節點的記錄查找時間越快， 只要找到關鍵字即可確定記錄的存在； 而 B+ 樹中每個記錄的查找時間基本是一樣的， 都需要從根節點走到葉子節點， 而且在葉子節點中還要再比較關鍵字。
2. 從這個角度看 B 樹的性能好像要比 B+ 樹好， 而在實際應用中卻是 B+ 樹的性能要好些。 因為 B+ 樹的非葉子節點不存放實際的數據，這樣每個節點可容納的元素個數比 B 樹多， 樹高比 B 樹小， 這樣帶來的好處是減少磁盤訪問次數。
3. 盡管 B+ 樹找到一個記錄所需的比較次數要比 B 樹多， 但是一次磁盤訪問的時間相當於成百上千次內存比較的時間， 因此實際中B+ 樹的性能可能還會好些， 而且 B+樹的葉子節點使用指針連接在一起， 方便順序遍歷（范圍搜索）， 這也是很多數據庫和文件系統使用 B+樹的緣故。

【性能提升】

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

【思考： 為什么說 B+樹比 B-樹更適合實際應用中操作系統的文件索引和數據庫索引？】

1. B+樹的磁盤讀寫代價更低：B+樹的內部結點並沒有指向關鍵字具體信息的指針。 因此其內部結點相對 B 樹更小。 如果把所有同一內部結點的關鍵字存放在同一盤塊中， 那么盤塊所能容納的關鍵字數量也越多。 一次性讀入內存中的需要查找的關鍵字也就越多。 相對來說 IO 讀寫次數也就降低了。
2. B+樹的查詢效率更加穩定：由於非終結點並不是最終指向文件內容的結點， 而只是葉子結點中關鍵字的索引。 所以任何關鍵字的查找必須走一條從根結點到葉子結點的路。 所有關鍵字查詢的路徑長度相同， 導致每一個數據的查詢效率相當。

image-20200811145838930

7、何時需要建索引

哪些情況下適合建立索引

1. 主鍵自動建立唯一索引
2. 頻繁作為查詢的條件的字段應該創建索引
3. 查詢中與其他表關聯的字段，外鍵關系建立索引
4. 頻繁更新的字段不適合創建索引
5. Where 條件里用不到的字段不創建索引
6. 單間/組合索引的選擇問題，Who？（在高並發下傾向創建組合索引）
7. 查詢中排序的字段，排序字段若通過索引去訪問將大大提高排序的速度
8. 查詢中統計或者分組字段

哪些情況不要創建索引

1. 表記錄太少
2. 經常增刪改的表
3. 數據重復且分布平均的表字段，因此應該只為經常查詢和經常排序的數據列建立索引。注意，如果某個數據列包含許多重復的內容，為它建立索引就沒有太大的實際效果。

---

案例分析：

1. 假如一個表有10萬行記錄，有一個字段A只有T和F兩種值，且每個值的分布概率大約為50%，那么對這種表A字段建索引一般不會提高數據庫的查詢速度。
2. 索引的選擇性是指索引列中不同值的數目與表中記錄數的比。如果一個表中有2000條記錄，表索引列有1980個不同的值，那么這個索引的選擇性就是1980/2000=0.99。
3. 一個索引的選擇性越接近於1，這個索引的效率就越高。

轉自此文章 與 B站此視頻