MySQL-Btree索引和Hash索引初探
文章目錄
- 生猛干貨
- 官方文檔
- MySQL支持的索引類型
- B樹索引
- B樹索引的特點
- 什么情況下會使用到B樹索引
- Btree索引的使用限制
- hash索引
- hash索引的特點
- hash索引的限制
- 為啥要使用索引
- 小結
- 搞定MySQL
生猛干貨
帶你搞定MySQL實戰，輕松對應海量業務處理及高并發需求，從容應對大場面試
官方文檔
https://dev.mysql.com/doc/
如果英文不好的話，可以參考 searchdoc 翻譯的中文版本
http://www.searchdoc.cn/rdbms/mysql/dev.mysql.com/doc/refman/5.7/en/index.com.coder114.cn.html
MySQL支持的索引類型
MySQL的索引是在存儲引擎層面實現的，而不是MySQL服務層。
B樹索引
B樹索引的特點
B-tree索引是以B+樹的結構存儲數據的。
那我們先簡單的來了解B+樹
- 平衡查找樹，每一個葉子節點到根節點的距離都是相同的
- 葉子結點都是按照順序從小到大排在同一層上
- 葉子節點是由指針來連接的
方案查找
B樹索引的特點
- B-tree索引能夠加快數據的查詢速度
- B-tree索引更適合進行范圍查找，因為數據 是順序存儲的
什么情況下會使用到B樹索引
這里我們以訂單表為例子來說明
-
全職匹配的查詢
在order_sn 上建立B樹索引
比如 查詢 訂單序列號 order_sn = ‘123456’
-
匹配最左前綴的查詢
舉個例子：訂單表 order_sn 沒有索引， 但有個聯合索引建在在 order_sn + order_date 這兩個字段上
當查詢 order_sn = ‘123456’ ----> 走索引
當查詢 order_sn = ‘123456’ and order_date = ‘2020-01-20’----> 走索引
當查詢 order_date = ‘2020-01-20’----> 不走索引這就是 匹配最左前綴的查詢
-
匹配列前綴查詢
舉個例子 在order_sn 上建立B樹索引
order_sn like '123% ' -------------> 走索引
-
匹配范圍值的查詢
比如 order_sn上建立索引
order_sn > '1000000' and order _sn < '1100000' -----------> 走索引
-
精確匹配左前列并范圍匹配另外一列
繼續使用例子： 訂單表 order_sn 沒有索引， 但有個聯合索引建在在 order_sn + order_date 這兩個字段上
比如 精確匹配 order_sn 但 order_date是個范圍查詢 -----> 走索引
-
只訪問索引的查詢
意思就是 order_sn上有索引， 我查詢的時候僅僅查詢這一列（索引列），而其他的數據列我不獲取。 效率非常高這種情況。
Btree索引的使用限制
-
如果不是按照索引最左列開始查找，則無法使用索引
繼續使用例子： 訂單表 order_sn 沒有索引， 但有個聯合索引建在在 order_sn + order_date 這兩個字段上
如果你僅僅查詢order_date , 這個聯合索引，是不會走的。
-
使用索引時不能跳過索引中的列
舉個例子： 3個列建立聯合索引 order_date + contact_people + contact_phone
如果你查詢中僅包含了 order_date 和 contact_phone , 對于這個查詢來講 ，只能使用到使用order-date來索引，而沒法走contact_people 了，因為你跳過了contact_people .
-
not int 和 <> 操作無法使用索引
-
如果查詢中有某個列的范圍查詢，則其右邊所有列都無法使用索引
hash索引
我們知道，索引是有存儲引起來實現的， 而MySQL的存儲引擎又是插件式的，所以其他的存儲引擎比如Memory存儲引擎就支持 hash 索引 和 B樹索引。 memory的默認索引就是hash索引，我們還是有必要了解下的。
innodb也支持hash索引，不夠不是由開發人員建立的，innodb內部自己定義的。
hash索引的特點
- 基于hash表實現， 只有查詢條件精確匹配時hash索引中的所有列時，才能夠使用到hash索引
- 對于hash索引中的所有列，存儲引擎都會為每一行計算一個hash碼，hash索引中存儲的就是這個hash碼
hash索引的限制
- hash索引必須進行二次查找 ，但基于內存，速度也挺快
- 無法用于排序
- 不支持部分索引操作 也不支持范圍查找
- hash碼的計算可能存在hash沖突
為啥要使用索引
- 索引大大減少 存儲引擎需要掃描的數據量
- 索引可以幫助我們進行排序以避免使用臨時表
- 索引可以把隨機I/O 變為 順序I/O
小結
索引不是越多越好 ，索引過多
-
對寫的影響： 過多索引會增加寫操作的成本，比如有的時候批量導入數據，你覺得慢，可以把索引先禁用，導入完成后再開啟索引
-
對讀的影響： 過多索引會增加查詢優化器的選擇時間。
搞定MySQL
總結
以上是生活随笔為你收集整理的MySQL-Btree索引和Hash索引初探的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： MySQL-通过MaxScale实现读写
- 下一篇： MySQL-索引优化篇(1)_安装演示库