索引在mysql中怎么存儲(chǔ)的

聚集索引：也稱 Clustered Index。是指關(guān)系表記錄的物理順序與索引的邏輯順序相同。由于一張表只能按照一種物理順序存放，一張表最多也只能存在一個(gè)聚集索引。與非聚集索引相比，聚集索引有著更快的檢索速度。

成都創(chuàng)新互聯(lián)制作網(wǎng)站網(wǎng)頁(yè)找三站合一網(wǎng)站制作公司,專注于網(wǎng)頁(yè)設(shè)計(jì),成都網(wǎng)站設(shè)計(jì)、成都網(wǎng)站制作、外貿(mào)網(wǎng)站建設(shè),網(wǎng)站設(shè)計(jì),企業(yè)網(wǎng)站搭建,網(wǎng)站開(kāi)發(fā),建網(wǎng)站業(yè)務(wù),680元做網(wǎng)站,已為近1000家服務(wù),成都創(chuàng)新互聯(lián)網(wǎng)站建設(shè)將一如既往的為我們的客戶提供最優(yōu)質(zhì)的網(wǎng)站建設(shè)、網(wǎng)絡(luò)營(yíng)銷推廣服務(wù)!

MySQL 里只有 INNODB 表支持聚集索引，INNODB 表數(shù)據(jù)本身就是聚集索引，也就是常說(shuō) IOT，索引組織表。非葉子節(jié)點(diǎn)按照主鍵順序存放，葉子節(jié)點(diǎn)存放主鍵以及對(duì)應(yīng)的行記錄。所以對(duì) INNODB 表進(jìn)行全表順序掃描會(huì)非常快。

非聚集索引：也叫 Secondary Index。指的是非葉子節(jié)點(diǎn)按照索引的鍵值順序存放，葉子節(jié)點(diǎn)存放索引鍵值以及對(duì)應(yīng)的主鍵鍵值。MySQL 里除了 INNODB 表主鍵外，其他的都是二級(jí)索引。MYISAM，memory 等引擎的表索引都是非聚集索引。簡(jiǎn)單點(diǎn)說(shuō)，就是索引與行數(shù)據(jù)分開(kāi)存儲(chǔ)。一張表可以有多個(gè)二級(jí)索引。

MySQL索引

MySQL的Innodb存儲(chǔ)引擎的索引分為聚集索引和非聚集索引兩大類

特點(diǎn)：B+樹(shù)葉子節(jié)點(diǎn)存儲(chǔ)行數(shù)據(jù)

一個(gè)表中，必須有一個(gè)聚集索引，只能有一個(gè)聚集索引，Innodb通常把一個(gè)表的主鍵索引作為聚集索引，如果沒(méi)有主鍵InnoDB會(huì)選擇一個(gè)唯一索引代替。如果沒(méi)有這樣的索引，InnoDB會(huì)隱式的定義一個(gè)主鍵來(lái)作為聚集索引，這個(gè)字段為6個(gè)字節(jié)，類型為長(zhǎng)整形。

利用主鍵索引查找行數(shù)據(jù)是最快的，建議使用自增主鍵原因是利于索引樹(shù)的構(gòu)建（主鍵自增寫入時(shí)新插入的數(shù)據(jù)不會(huì)影響到原有頁(yè)，插入效率高；但是如果主鍵是無(wú)序的或者隨機(jī)的，那每次的插入可能會(huì)導(dǎo)致原有頁(yè)頻繁的分裂，影響插入效率）

特點(diǎn)：B+樹(shù)葉子節(jié)點(diǎn)存儲(chǔ)主鍵ID

一個(gè)表中可以有多個(gè)非聚集索引，每個(gè)非聚集索引即是一棵B+樹(shù)

通過(guò)非聚集索引查找數(shù)據(jù)時(shí)，需要先在非聚集索引上找到主鍵ID，再?gòu)木奂饕@取行數(shù)據(jù)，這個(gè)過(guò)程就稱之為回表

B樹(shù)索引中的B樹(shù)實(shí)際上是B+樹(shù)，至于為什么使用B+樹(shù)而不使用B樹(shù)或者紅黑樹(shù)的原因在另外的文章中有提及。

特點(diǎn)：

特點(diǎn)：類似JDK中的HashMap，但無(wú)法支持范圍查詢

特點(diǎn)：使用的算法仍然是B樹(shù)索引，不同的就是索引列的值必須唯一

對(duì)于普通索引來(lái)說(shuō)，查找到滿足條件的第一個(gè)記錄后，需要查找下一個(gè)記錄，直到碰到第一個(gè)不滿足條件的記錄。

對(duì)于唯一索引來(lái)說(shuō)，由于索引定義了唯一性，查找到第一個(gè)滿足條件的記錄后，就會(huì)停止繼續(xù)檢索，提升索引性能

另外插入行時(shí)會(huì)構(gòu)建該唯一索引，假如索引值重復(fù)將插入失敗，適合業(yè)務(wù)上做唯一性檢驗(yàn)

通過(guò)建立倒排索引，可以極大的提升檢索效率,解決判斷字段是否包含的問(wèn)題，但是業(yè)務(wù)上一般都不采用這種索引，而是使用ES處理全文搜索需求

僅對(duì)某個(gè)特定字段建立的索引，如(biz_id)

對(duì)多個(gè)字段建立的索引，如(biz_id,type)

Mysql InnoDB索引原理

理解Mysql索引的原理和數(shù)據(jù)結(jié)構(gòu)有助于我們更好的使用索引以及進(jìn)行SQL優(yōu)化，索引是在存儲(chǔ)引擎層面實(shí)現(xiàn)的，所以不同的引擎實(shí)現(xiàn)的索引也有一定的區(qū)別，但是在生產(chǎn)環(huán)境中，我們最常用的就是InnoDB引擎和B樹(shù)索引，OK，那本文要討論的重點(diǎn)也同樣是 InnoDB引擎下的B樹(shù)索引 。

我們建立一個(gè)表來(lái)進(jìn)行測(cè)試，表的DDL如下所示，我們要關(guān)注的是表t_book上的主鍵索引id和name author publish_date三列組成的索引test_index。

Mysql中的B樹(shù)索引是使用B+樹(shù)實(shí)現(xiàn)的，關(guān)于B+樹(shù)的數(shù)據(jù)結(jié)構(gòu)個(gè)人認(rèn)為美團(tuán)點(diǎn)評(píng)技術(shù)博客中Mysql索引原理及慢查詢優(yōu)化一文中介紹的非常詳實(shí)，B+樹(shù)的數(shù)據(jù)結(jié)構(gòu)如下圖所示。

圖中淺藍(lán)色塊即磁盤塊，根節(jié)點(diǎn)磁盤塊中存儲(chǔ)17和35兩個(gè)數(shù)據(jù)，其中指針P1指向小于17的數(shù)據(jù)，指針P2指向大于17小于35的數(shù)據(jù)，指針P3指向大于35的數(shù)據(jù)。顯然通過(guò)B+樹(shù)索引查詢數(shù)據(jù)與B+樹(shù)的高度有關(guān)，如上圖的B+樹(shù)索引查找一個(gè)葉子節(jié)點(diǎn)的數(shù)據(jù)只需要三次磁盤IO，對(duì)于Mysql來(lái)說(shuō)三層的B+樹(shù)可以索引上百萬(wàn)的數(shù)據(jù)，這對(duì)于查詢效率的提升是巨大的。

總結(jié)起來(lái)Mysql中B樹(shù)索引有以下關(guān)鍵特點(diǎn)：

Mysql中的B樹(shù)索引有兩種數(shù)據(jù)存儲(chǔ)形式，一種為聚簇索引，一種為二級(jí)索引。

InnoDB一般會(huì)使用表的主鍵來(lái)作為聚簇索引，如果一個(gè)表沒(méi)有主鍵（不建議這么玩）InnoDB會(huì)選用一個(gè)唯一非空索引來(lái)代替，如果沒(méi)有這樣的索引，InnoDB會(huì)隱式建立一個(gè)聚簇索引。聚簇的含義即是數(shù)據(jù)行和相鄰的鍵值緊湊的存儲(chǔ)在一起，占據(jù)一塊連續(xù)的磁盤空間，因此通過(guò)聚簇索引訪問(wèn)數(shù)據(jù)可以有效減少隨機(jī)IO，通常使用聚簇索引查找比非聚簇索引查找速度更快。以我們建立的表t_book為例，聚簇索引即為自增主鍵id，其B樹(shù)索引數(shù)據(jù)結(jié)構(gòu)可以用下圖來(lái)表示。

聚簇索引有以下關(guān)鍵特點(diǎn)：

InnoDB的B樹(shù)索引中除了聚簇索引，就都是二級(jí)索引了，二級(jí)索引的含義是索引的葉子節(jié)點(diǎn)除了存儲(chǔ)了索引值，還存儲(chǔ)了主鍵id，在使用二級(jí)索引進(jìn)行查詢時(shí)，查找到二級(jí)索引B樹(shù)上的葉子節(jié)點(diǎn)后還需要去聚簇索引上去查詢真實(shí)數(shù)據(jù)，但是這里有一種特殊情況，即查詢所需的所有字段在二級(jí)索引中都可以獲取，此時(shí)就不需要再去回表查數(shù)據(jù)了，這種情況就是索引覆蓋（EXPLAIN中EXTRA列中會(huì)出現(xiàn)USING INDEX，本文只關(guān)注索引結(jié)構(gòu)，不詳細(xì)討論索引覆蓋等技術(shù)的使用，如果深入理解索引的數(shù)據(jù)結(jié)構(gòu)，索引覆蓋等技術(shù)也沒(méi)有那么神秘）。

在我們的測(cè)試表t_book中，test_index即為二級(jí)索引，由于我們把除了主鍵id所有的列都作為一個(gè)聯(lián)合索引，所以在這個(gè)表上的查詢都可以使用索引覆蓋技術(shù)，但是具體生產(chǎn)環(huán)境中也不建議總是采用這種做法，索引列的增加也會(huì)增大插入更新數(shù)據(jù)時(shí)的索引更新成本，具體的優(yōu)化要視具體情況決策。t_book上的二級(jí)索引test_index的索引結(jié)構(gòu)由下圖表示。

通過(guò)以上結(jié)構(gòu)，我們可以推斷出二級(jí)索引的以下關(guān)鍵特點(diǎn)：

索引覆蓋：

最左前綴匹配：

二級(jí)索引可以說(shuō)是我們?cè)贛ysql中最常用的索引，通過(guò)理解二級(jí)索引的索引結(jié)構(gòu)可以更容易理解二級(jí)索引的特性和使用。

最后聊點(diǎn)輕松的索引結(jié)構(gòu)，哈希索引就是通過(guò)哈希表實(shí)現(xiàn)的索引，即通過(guò)被索引的列計(jì)算出哈希值，并指向被索引的記錄。

哈希索引有如下特性：

Mysql索引原理及慢查詢優(yōu)化

高性能Mysql 第三版

「Mysql索引原理（六）」聚簇索引

? ?本節(jié)課主要關(guān)注InnoDB，但是這里討論的原理對(duì)于任何支持聚簇索引的存儲(chǔ)引擎都是適用的。

? ?葉子節(jié)點(diǎn)包含了全部數(shù)據(jù)，其他節(jié)點(diǎn)只包含索引列。InnoDB將通過(guò)主鍵聚集數(shù)據(jù)，也就是說(shuō)上圖中的“被索引的列”就是主鍵列。如果沒(méi)有定義主鍵，InnoDB會(huì)選擇一個(gè)唯一的非空索引代替。如果沒(méi)有這樣的索引InnoDB會(huì)隱式定義一個(gè)主鍵來(lái)作為聚簇索引。

? ?如果主鍵比較大的話，那輔助索引將會(huì)變的更大，因?yàn)?輔助索引的葉子存儲(chǔ)的是主鍵值；過(guò)長(zhǎng)的主鍵值，會(huì)導(dǎo)致非葉子節(jié)點(diǎn)占用占用更多的物理空間

所以建議使用int的auto_increment作為主鍵

? ?主鍵的值是順序的，所以 InnoDB 把每一條記錄都存儲(chǔ)在上一條記錄的后面。當(dāng)達(dá)到頁(yè)的最大值時(shí)，下一條記錄就會(huì)寫入新的頁(yè)中。一旦數(shù)據(jù)按照這種順序的方式加載，主鍵頁(yè)就會(huì)近似于被順序的記錄填滿。

? ?聚簇索引的數(shù)據(jù)的物理存放順序與索引順序是一致的，即：只要索引是相鄰的，那么對(duì)應(yīng)的數(shù)據(jù)一定也是相鄰地存放在磁盤上的。如果主鍵不是自增id，那么可以想 象，它會(huì)干些什么，不斷地調(diào)整數(shù)據(jù)的物理地址、分頁(yè)，當(dāng)然也有其他一些措施來(lái)減少這些操作，但卻無(wú)法徹底避免。但，如果是自增的，那就簡(jiǎn)單了，它只需要一 頁(yè)一頁(yè)地寫，索引結(jié)構(gòu)相對(duì)緊湊，磁盤碎片少，效率也高。

? ?因?yàn)镸yISAM的主索引并非聚簇索引，那么他的數(shù)據(jù)的物理地址必然是凌亂的，拿到這些物理地址，按照合適的算法進(jìn)行I/O讀取，于是開(kāi)始不停的尋道不停的旋轉(zhuǎn)。聚簇索引則只需一次I/O。（強(qiáng)烈的對(duì)比）

? ?不過(guò)，如果涉及到大數(shù)據(jù)量的排序、全表掃描、count之類的操作的話，還是MyISAM占優(yōu)勢(shì)些，因?yàn)樗饕伎臻g小，這些操作是需要在內(nèi)存中完成的。

? ?MyISM使用的是非聚簇索引， 非聚簇索引的兩棵B+樹(shù)看上去沒(méi)什么不同 ，節(jié)點(diǎn)的結(jié)構(gòu)完全一致只是存儲(chǔ)的內(nèi)容不同而已，主鍵索引B+樹(shù)的節(jié)點(diǎn)存儲(chǔ)了主鍵，輔助鍵索引B+樹(shù)存儲(chǔ)了輔助鍵。表數(shù)據(jù)存儲(chǔ)在獨(dú)立的地方，這兩顆B+樹(shù)的葉子節(jié)點(diǎn)都使用一個(gè)地址指向真正的表數(shù)據(jù)，對(duì)于表數(shù)據(jù)來(lái)說(shuō)，這兩個(gè)鍵沒(méi)有任何差別。由于 索引樹(shù)是獨(dú)立的，通過(guò)輔助鍵檢索無(wú)需訪問(wèn)主鍵的索引樹(shù) 。

? ?所以說(shuō)，聚簇索引性能最好而且具有唯一性，所以非常珍貴，必須慎重設(shè)置。 一般要根據(jù)這個(gè)表最常用的SQL查詢方式來(lái)進(jìn)行選擇，某個(gè)字段作為聚簇索引，或組合聚簇索引 ，這個(gè)要看實(shí)際情況。

? ?聚簇索引和非聚簇索引的數(shù)據(jù)分布有區(qū)別，主鍵索引和二級(jí)索引的數(shù)據(jù)分布也有區(qū)別，通常會(huì)讓人感到困擾和以外，下面通過(guò)一個(gè)列子來(lái)講解InnoDB和MyISAM是如何存儲(chǔ)數(shù)據(jù)的：

? ?該表的主鍵取值1~10000，按照隨機(jī)順序插入并使用optimize table命令做了優(yōu)化。換句話說(shuō)，數(shù)據(jù)在磁盤上的存儲(chǔ)方式已是最優(yōu)，但行的順序是隨機(jī)的。列col2的值是從1~100之間隨機(jī)賦值，所以有很多重復(fù)的值。

? ?MyISAM的數(shù)據(jù)分布很簡(jiǎn)單，所以先介紹它。MyISAM按照數(shù)據(jù)插入的順序存儲(chǔ)在磁盤上，如下圖所示：

在行的旁邊顯示行號(hào)，從0開(kāi)始遞增。因?yàn)樾惺嵌ㄩL(zhǎng)的，所以MyISAM可以從表的開(kāi)頭跳過(guò)所需的字節(jié)找到需要的行。

col2上的索引

? ?事實(shí)上，MyISAM中主鍵索引和其他索引在結(jié)構(gòu)上沒(méi)有什么不同。主鍵索引就是一個(gè)名為PRIMARY的唯一非空索引。

? ?InnoDB支持聚簇索引，所以使用不同的方式存儲(chǔ)同樣的數(shù)據(jù)。

? ?第一眼看上去，感覺(jué)和前面的沒(méi)什么區(qū)別，但是該圖顯示了整個(gè)表，而不是只有索引。因?yàn)樵贗nnoDB中，聚簇索引就是表，所以不像MyISAM那樣需要獨(dú)立的行存儲(chǔ)，這也是為什么MyISAM索引和數(shù)據(jù)結(jié)構(gòu)是分開(kāi)的。

? ?聚簇索引的每一個(gè)葉子節(jié)點(diǎn)都包含了主鍵值。事務(wù)ID、用于事務(wù)和MVCC的回滾指針以及所有的剩余列。如果主鍵是一個(gè)列前綴索引，InnoDB也會(huì)包含完整的主鍵列和剩下的其他列。

? ?還有一點(diǎn)和MyISAM不同的是，InnoDB的二級(jí)索引和聚簇索引很不相同。InnoDB的二級(jí)索引的葉子節(jié)點(diǎn)中存儲(chǔ)的不是“行指針”，而是主鍵值，并以此作為指向行的“指針”。這樣的策略減少了當(dāng)出現(xiàn)行移動(dòng)或者數(shù)據(jù)頁(yè)分裂時(shí)二級(jí)索引的維護(hù)工作。使用主鍵值當(dāng)作指針會(huì)讓二級(jí)索引占用更多的空間，換來(lái)的好處是，InnoDB在移動(dòng)時(shí)無(wú)需更新二級(jí)索引中的這個(gè)“指針”。

? ?我們?cè)趤?lái)看一下 col2索引 。

? ?每一個(gè)葉子節(jié)點(diǎn)包含了索引列（這里是col2），緊接著是主鍵值（col1），上圖我們省略了非葉子節(jié)點(diǎn)這樣的細(xì)節(jié)。InnoDB非葉子節(jié)點(diǎn)包含了索引列和一個(gè)指向下一級(jí)節(jié)點(diǎn)的指針。

? ?最后，以一張圖表示InnoDB和MyISAM保存數(shù)據(jù)和索引的區(qū)別。

? ?前面講過(guò)，最好使用AUTO_INCREMENT自增列來(lái)聚集數(shù)據(jù)，避免隨機(jī)的、不連續(xù)的、值分布范圍大的列做聚簇索引，特別是對(duì)于I/O密集型的應(yīng)用。例如，從性能角度考慮，使用UUID來(lái)作為聚簇索引則會(huì)很糟糕：他使得聚簇索引的插入變得完全隨機(jī)，這是最壞的情況，使得數(shù)據(jù)沒(méi)有任何聚集特性。

? ?為了演示這一點(diǎn)，我們做兩個(gè)基準(zhǔn)測(cè)試：

1、使用證書ID插入userinfo表，和uuid作為主鍵的userinfo_uuid表

? ?userinfo_uuid表跟userinfo表除了主鍵給為UUID，其他字段都一樣

? ?測(cè)試這兩個(gè)表的設(shè)計(jì)，首先在一個(gè)有足夠內(nèi)存容納索引的服務(wù)器上向這兩個(gè)表各插入100萬(wàn)條記錄。然后向兩個(gè)表繼續(xù)插入300萬(wàn)數(shù)據(jù)，使索引的大小超過(guò)服務(wù)器的內(nèi)存容量。測(cè)試結(jié)果如下：

? ?向UUID主鍵插入行不僅花費(fèi)的時(shí)間更長(zhǎng)，而且索引占用的空間也更大。這一方面是由于主鍵字段更長(zhǎng)，另一方面毫無(wú)疑問(wèn)是由于頁(yè)分裂和碎片導(dǎo)致的。

? ?為了明白為什么會(huì)這樣，來(lái)看看往第一個(gè)表中插入數(shù)據(jù)時(shí)，索引發(fā)生了什么變化。

自整型主鍵插入

? ?因?yàn)橹麈I是順序的，所以InnoDB把每一條記錄都存在上一條記錄的后面。當(dāng)達(dá)到頁(yè)的最大容量后，下一條記錄就會(huì)寫入到新的頁(yè)中。一旦數(shù)據(jù)按照這種順序的方式加載，主鍵頁(yè)就會(huì)近似于被順序的記錄填滿，這也正是所期望的結(jié)果。

UUID插入

? ?因?yàn)樾滦械闹麈I值不一定比之前插入的大，所以InnoDB無(wú)法簡(jiǎn)單的總是把新行插入到索引的最后，而是需要為新的行尋找合適的位置，通常是已有數(shù)據(jù)的中間位置，并且分配空間。這會(huì)正價(jià)很多的額外工作，并導(dǎo)致數(shù)據(jù)分布不夠優(yōu)化。

缺點(diǎn)：

把這些隨機(jī)值載入到聚簇索引后，也許需要做一次OPTIMIZE TABLE來(lái)重建表并優(yōu)化頁(yè)的填充。

結(jié)論 ：使用InnoDB時(shí)應(yīng)盡可能地按主鍵順序插入數(shù)據(jù)，并且盡可能地單調(diào)增加聚簇鍵的值來(lái)插入新行。

網(wǎng)站標(biāo)題：mysql索引怎么存儲(chǔ)的,如何導(dǎo)出mysql索引
標(biāo)題網(wǎng)址：http://chinadenli.net/article22/dsgjicc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供手機(jī)網(wǎng)站建設(shè)、定制開(kāi)發(fā)、微信公眾號(hào)、動(dòng)態(tài)網(wǎng)站、網(wǎng)站收錄、自適應(yīng)網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)