共計(jì) 1956 個(gè)字符，預(yù)計(jì)需要花費(fèi) 5 分鐘才能閱讀完成。
本篇文章給大家分享的是有關(guān) MySQL 中索引類型的實(shí)現(xiàn)原理是什么，丸趣 TV 小編覺(jué)得挺實(shí)用的，因此分享給大家學(xué)習(xí)，希望大家閱讀完這篇文章后可以有所收獲，話不多說(shuō)，跟著丸趣 TV 小編一起來(lái)看看吧。
一、按表列屬性分類：
1. 單列索引
以表的單個(gè)列字段創(chuàng)建的索引
2. 聯(lián)合索引
以表的多個(gè)列字段組合創(chuàng)建的索引，在查詢條件使用索引的從左字段順序才會(huì)生效，遵循最左匹配原則。
單列索引和聯(lián)合索引又包括：
普通索引
非主鍵，非唯一列的索引
主鍵索引
基于該表主鍵自動(dòng)生成成的索引，如果未給表定義主鍵，會(huì)查找該表中是否存在非空、整形、唯一索引作為其主鍵 (可通過(guò) select _rowid from
表名查看 )，若都不滿足會(huì)隱式生成一個(gè) rowid 作為主鍵 (無(wú)法直接查到)
唯一索引
基于表的唯一列生成的索引，允許為空值
全文索引
將存儲(chǔ)于數(shù)據(jù)庫(kù)中的整本書(shū)或整篇文章中任意內(nèi)容信息查找出來(lái)，如大量級(jí)的文字中如 like % 關(guān)鍵字 %，普通索引的效率與全文索引相比是非常低的。
二、按數(shù)據(jù)結(jié)構(gòu)分類：
1.B+tree 索引
b+tree 基于平衡二叉樹(shù)的一種多路平衡查找樹(shù)，所有記錄都按照順序存放在葉子節(jié)點(diǎn)中，各個(gè)葉子節(jié)點(diǎn)直接通過(guò)鏈表相連。與 b 樹(shù)不同的是：
非葉子節(jié)點(diǎn)只存儲(chǔ)鍵值信息。
所有葉子節(jié)點(diǎn)之間都有一個(gè)鏈指針。
數(shù)據(jù)記錄都存放在葉子節(jié)點(diǎn)中。
2.hash 索引
基于 hash 表結(jié)構(gòu)實(shí)現(xiàn)的索引，mysql 中只有 MEMORY/HEAP 和 NDB 存儲(chǔ)引擎支持;
InnoDB 引擎支持自適應(yīng) hash 索引，但是是數(shù)據(jù)庫(kù)自身創(chuàng)建使用的，而不能進(jìn)行人為定義。當(dāng)二級(jí)索引被頻繁的訪問(wèn)時(shí)，便會(huì)自動(dòng)創(chuàng)建自適應(yīng)哈希索引;
通過(guò) 命令 SHOW ENGINE INNODB STATUS 可查看自適應(yīng) hash 索引的使用情況;
通過(guò) 命令 SHOW VARIABLES LIKE %ap%hash_index 查看是否打開(kāi)自適應(yīng) hash 索引。
對(duì)比：
由于 hash 索引是比較其 hash 值，hash 索引只能進(jìn)行等值查找而不能進(jìn)行范圍查找
hash 索引無(wú)法進(jìn)行排序：原因同上
不支持最左匹配原則，復(fù)合索引時(shí)合并一起計(jì)算 hash 值
hash 索引的檢索效率很高可以一次定位，但是當(dāng)發(fā)生大量 hash 碰撞的時(shí)候，鏈表變長(zhǎng)，hash 索引效率上是不如 b +tree 的
由于存在 hash 碰撞的問(wèn)題，當(dāng)需要獲得總數(shù)時(shí)候，hash 索引在任何時(shí)候都不能避免表掃描
3.T-tree 索引無(wú)錫人流醫(yī)院哪家好 http://www.wxbhnkyy120.com/
4.R-tree 索引
三、按存儲(chǔ)結(jié)構(gòu)分類：
1. 聚簇索引 (聚集索引)
InnoDB 的聚簇索引實(shí)際上是在同一個(gè) BTree 結(jié)構(gòu)中同時(shí)存儲(chǔ)了索引和整行數(shù)據(jù)，通過(guò)該索引查詢可以直接獲取查詢數(shù)據(jù)行。
聚簇索引不是一種單獨(dú)的索引類型，而是一種數(shù)據(jù)的存儲(chǔ)方式，聚簇索引的順序，就是數(shù)據(jù)在硬盤上的物理順序。
在 mysql 通常聚簇索引是主鍵的同義詞，每張表只包含一個(gè)聚簇索引 (其他數(shù)據(jù)庫(kù)不一定)。
2. 輔助索引 (非聚集索引，次級(jí)索引，二級(jí)索引)
非聚集索引在 BTree 的葉子節(jié)點(diǎn)中保存了索引列和主鍵。如果查詢列不在該索引內(nèi)，只能查到其主鍵值，還需要回表操作查詢聚簇索引進(jìn)行查詢。
聚簇索引的優(yōu)點(diǎn)：
可以把相關(guān)數(shù)據(jù)保存在一起，如：實(shí)現(xiàn)電子郵箱時(shí)，可以根據(jù)用戶 ID 來(lái)聚集數(shù)據(jù)，這樣只需要從磁盤讀取少量的數(shù)據(jù)頁(yè)就能獲取某個(gè)用戶全部郵件，如果沒(méi)有使用聚集索引，則每封郵件都可能導(dǎo)致一次磁盤 IO
數(shù)據(jù)訪問(wèn)更快，聚集索引將索引和數(shù)據(jù)保存在同一個(gè) btree 中，因此從聚集索引中獲取數(shù)據(jù)通常比在非聚集索引中查找要快
使用覆蓋索引掃描的查詢可以直接使用頁(yè)節(jié)點(diǎn)中的主鍵值
聚簇索引的缺點(diǎn)：
聚簇?cái)?shù)據(jù)最大限度地提高了 IO 密集型應(yīng)用的性能，但如果數(shù)據(jù)全部放在內(nèi)存中，則訪問(wèn)的順序就沒(méi)有那么重要了，聚集索引也沒(méi)有什么優(yōu)勢(shì)了
插入速度嚴(yán)重依賴于插入順序，按照主鍵的順序插入是加載數(shù)據(jù)到 innodb 表中速度最快的方式，但如果不是按照主鍵順序加載數(shù)據(jù)，那么在加載完成后最好使用 optimize
table 命令重新組織一下表
更新聚集索引列的代價(jià)很高，因?yàn)闀?huì)強(qiáng)制 innodb 將每個(gè)被更新的行移動(dòng)到新的位置
基于聚集索引的表在插入新行，或者主鍵被更新導(dǎo)致需要移動(dòng)行的時(shí)候，可能面臨頁(yè)分裂的問(wèn)題，當(dāng)行的主鍵值要求必須將這一行插入到某個(gè)已滿的頁(yè)中時(shí)，存儲(chǔ)引擎會(huì)將該頁(yè)分裂成兩個(gè)頁(yè)面來(lái)容納該行，這就是一次頁(yè)分裂操作，頁(yè)分裂會(huì)導(dǎo)致表占用更多的磁盤空間
聚集索引可能導(dǎo)致全表掃描變慢，尤其是行比較稀疏，或者由于頁(yè)分裂導(dǎo)致數(shù)據(jù)存儲(chǔ)不連續(xù)的時(shí)候
二級(jí)索引可能比想象的更大，因?yàn)樵诙?jí)索引的葉子節(jié)點(diǎn)包含了引用行的主鍵列。
二級(jí)索引訪問(wèn)需要兩次索引查找，而不是一次
以上就是 MySQL 中索引類型的實(shí)現(xiàn)原理是什么，丸趣 TV 小編相信有部分知識(shí)點(diǎn)可能是我們?nèi)粘９ぷ鲿?huì)見(jiàn)到或用到的。希望你能通過(guò)這篇文章學(xué)到更多知識(shí)。更多詳情敬請(qǐng)關(guān)注丸趣 TV 行業(yè)資訊頻道。
