一、索引的簡(jiǎn)介

1、索引的概念

MySQL官方對(duì)索引的定義為：索引（Index）是幫助MySQL高效獲取數(shù)據(jù)的數(shù)據(jù)結(jié)構(gòu)。

索引的本質(zhì)：索引是數(shù)據(jù)結(jié)構(gòu)。你可以簡(jiǎn)單理解為“排好序的快速查找數(shù)據(jù)結(jié)構(gòu)”，滿(mǎn)足特定查找算法。這些數(shù)據(jù)結(jié)構(gòu)以某種方式指向數(shù)據(jù)， 這樣就可以在這些數(shù)據(jù)結(jié)構(gòu)的基礎(chǔ)上實(shí)現(xiàn) 高級(jí)查找算法

2、索引的優(yōu)點(diǎn)

• 類(lèi)似大學(xué)圖書(shū)館建書(shū)目索引，提高數(shù)據(jù)檢索的效率，降低數(shù)據(jù)庫(kù)的IO成本 ，這也是創(chuàng)建索引最主要的原因。
• 通過(guò)創(chuàng)建唯一索引，可以保證數(shù)據(jù)庫(kù)表中每一行 數(shù)據(jù)的唯一性 。
• 在實(shí)現(xiàn)數(shù)據(jù)的參考完整性方面，可以 加速表和表之間的連接。換句話說(shuō)，對(duì)于有依賴(lài)關(guān)系的子表和父表聯(lián)合查詢(xún)時(shí)，可以提高查詢(xún)速度。
• 在使用分組和排序子句進(jìn)行數(shù)據(jù)查詢(xún)時(shí)，可以顯著 減少查詢(xún)中分組和排序的時(shí)間 ，降低了CPU的消耗。

3、索引的缺點(diǎn)

• 創(chuàng)建索引和維護(hù)索引要 耗費(fèi)時(shí)間 ，并且隨著數(shù)據(jù)量的增加，所耗費(fèi)的時(shí)間也會(huì)增加。
• 索引需要占 磁盤(pán)空間 ，除了數(shù)據(jù)表占數(shù)據(jù)空間之外，每一個(gè)索引還要占一定的物理空間， 存儲(chǔ)在磁盤(pán)上 ，如果有大量的索引，索引文件就可能比數(shù)據(jù)文件更快達(dá)到最大文件尺寸。
• 雖然索引大大提高了查詢(xún)速度，同時(shí)卻會(huì) 降低更新表的速度 。當(dāng)對(duì)表中的數(shù)據(jù)進(jìn)行增加、刪除和修改的時(shí)候，索引也要?jiǎng)討B(tài)地維護(hù)，這樣就降低了數(shù)據(jù)的維護(hù)速度。

二、索引的代價(jià)

索引是個(gè)好東西，可不能亂建，它在空間和時(shí)間上都會(huì)有消耗：

1、空間上的代價(jià)

每建立一個(gè)索引都要為它建立一棵B+樹(shù)，每一棵B+樹(shù)的每一個(gè)節(jié)點(diǎn)都是一個(gè)數(shù)據(jù)頁(yè)，一個(gè)頁(yè)默認(rèn)會(huì)占用 16KB 的存儲(chǔ)空間，一棵很大的B+樹(shù)由許多數(shù)據(jù)頁(yè)組成，那就是很大的一片存儲(chǔ)空間。
時(shí)間上的代價(jià)

2、時(shí)間上的代價(jià)

每次對(duì)表中的數(shù)據(jù)進(jìn)行 增、刪、改 操作時(shí)，都需要去修改各個(gè)B+樹(shù)索引。而且我們講過(guò)，B+樹(shù)每層節(jié)點(diǎn)都是按照索引列的值 從小到大的順序排序 而組成了 雙向鏈表 。不論是葉子節(jié)點(diǎn)中的記錄，還是內(nèi)節(jié)點(diǎn)中的記錄（也就是不論是用戶(hù)記錄還是目錄項(xiàng)記錄）都是按照索引列的值從小到大的順序而形成了一個(gè)單向鏈表。而增、刪、改操作可能會(huì)對(duì)節(jié)點(diǎn)和記錄的排序造成破壞，所以存儲(chǔ)引擎需要額外的時(shí)間進(jìn)行一些 記錄移位 ， 頁(yè)面分裂 、 頁(yè)面回收 等操作來(lái)維護(hù)好節(jié)點(diǎn)和記錄的排序。如果我們建了許多索引，每個(gè)索引對(duì)應(yīng)的B+樹(shù)都要進(jìn)行相關(guān)的維護(hù)操作，會(huì)給性能拖后腿。

三、InnoDB中索引的推演

1、設(shè)計(jì)索引

可以聯(lián)想操作系統(tǒng)中的頁(yè)表機(jī)制，一層套一層（通過(guò)目錄項(xiàng)找頁(yè)，當(dāng)目錄項(xiàng)中過(guò)多時(shí)，我們會(huì)繼續(xù)設(shè)置目錄項(xiàng)去找目錄項(xiàng)…），最后形成B+樹(shù)的形式

1）以c1創(chuàng)建索引（因?yàn)閏1是主鍵）

mysql> CREATE TABLE index_demo(
 ->   c1 INT,
 ->   c2 INT,
 ->   c3 CHAR(1),
 ->   PRIMARY KEY(c1)
 -> ) ROW_FORMAT = Compact;

2）數(shù)據(jù)庫(kù)中一條記錄的格式

• record_type ：記錄頭信息的一項(xiàng)屬性，表示記錄的類(lèi)型， 0 表示普通記錄、 2 表示最小記錄、 3 表示最大記錄、 1 是目錄項(xiàng)。
• next_record：記錄頭信息的一項(xiàng)屬性，表示下一條地址相對(duì)于本條記錄的地址偏移量，我們用箭頭來(lái)表明下一條記錄是誰(shuí)。
• 各個(gè)列的值 ：這里只記錄在 index_demo 表中的三個(gè)列，分別是 c1 、 c2 和 c3 。
• 其他信息 ：除了上述3種信息以外的所有信息，包括其他隱藏列的值以及記錄的額外信息。

3）將記錄放在數(shù)據(jù)頁(yè)中

數(shù)據(jù)庫(kù)中的數(shù)據(jù)在磁盤(pán)中是以數(shù)據(jù)頁(yè)的形式進(jìn)行存儲(chǔ)的，每一頁(yè)中的每一行叫做記錄

頁(yè)內(nèi)的數(shù)據(jù)是按照主鍵值進(jìn)行排序的，所以頁(yè)內(nèi)數(shù)據(jù)我們是可以通過(guò)二分法去查找的。

4）當(dāng)頁(yè)過(guò)多時(shí)，需要為頁(yè)設(shè)置目錄項(xiàng)

5）當(dāng)目錄項(xiàng)過(guò)多時(shí)，我們需要為目錄項(xiàng)設(shè)置目錄項(xiàng)

6）最后形成B+樹(shù)的形式

一個(gè)B+樹(shù)的節(jié)點(diǎn)其實(shí)可以分成好多層，規(guī)定最下邊的那層，也就是存放我們用戶(hù)記錄的那層為第 0層，之后依次往上加。之前我們做了一個(gè)非常極端的假設(shè)：存放用戶(hù)記錄的頁(yè)最多存放3條記錄 ，存放目錄項(xiàng)記錄的頁(yè) 最多存放4條記錄 。其實(shí)真實(shí)環(huán)境中一個(gè)頁(yè)存放的記錄數(shù)量是非常大的（MySQL中一頁(yè)的大小為16KB），假設(shè)所有存放用戶(hù)記錄的葉子節(jié)點(diǎn)代表的數(shù)據(jù)頁(yè)可以存放100條用戶(hù)記錄，所有存放目錄項(xiàng)記錄的內(nèi)節(jié)點(diǎn)代表的數(shù)據(jù)頁(yè)可以存放1000條目錄項(xiàng)記錄 ，那么：

• 如果B+樹(shù)只有1層，也就是只有1個(gè)用于存放用戶(hù)記錄的節(jié)點(diǎn)，最多能存放 100 條記錄。
• 如果B+樹(shù)有2層，最多能存放 1000×100=10,0000 條記錄。
• 如果B+樹(shù)有3層，最多能存放 1000×1000×100=1,0000,0000 條記錄。
• 如果B+樹(shù)有4層，最多能存放 1000×1000×1000×100=1000,0000,0000 條記錄。相當(dāng)多的記錄?。?！

因此，面試中問(wèn)，為什么MySQL的B+樹(shù)最多只有四層？
因?yàn)樗膶泳鸵呀?jīng)能夠存儲(chǔ)相當(dāng)量的數(shù)據(jù)了，足夠我們使用，畢竟四層可以存儲(chǔ)100000000000 條記錄了。

那怎么去查找我們所需要的的記錄了？
通過(guò)主鍵值去查找某條記錄最多只需要做4個(gè)頁(yè)面內(nèi)的查找（查找3個(gè)目錄項(xiàng)頁(yè)和一個(gè)用戶(hù)記錄頁(yè)），又因?yàn)樵诿總€(gè)頁(yè)面內(nèi)有所謂的 Page Directory（頁(yè)目錄），所以在頁(yè)面內(nèi)也可以通過(guò) 二分法 實(shí)現(xiàn)快速定位記錄

2、常見(jiàn)索引概念

2.1、聚簇索引

1、特點(diǎn)

上面舉的例子是基于主鍵進(jìn)行排序的，所以是聚簇索引！

• 使用記錄主鍵值的大小進(jìn)行記錄和頁(yè)的排序，這包括三個(gè)方面的含義：
  • 頁(yè)內(nèi) 的記錄是按照主鍵的大小順序排成一個(gè) 單向鏈表。
  • 各個(gè)存放 用戶(hù)記錄的頁(yè) 也是根據(jù)頁(yè)中用戶(hù)記錄的主鍵大小順序排成一個(gè) 雙向鏈表 。
  • 存放目錄項(xiàng)記錄的頁(yè) 分為不同的層次，在同一層次中的頁(yè)也是根據(jù)頁(yè)中目錄項(xiàng)記錄的主鍵大小順序排成一個(gè) 雙向鏈表。
• B+樹(shù)的 葉子節(jié)點(diǎn) 存儲(chǔ)的是完整的用戶(hù)記錄。
  所謂完整的用戶(hù)記錄，就是指這個(gè)記錄中存儲(chǔ)了所有列的值（包括隱藏列）

2、優(yōu)點(diǎn)

• 數(shù)據(jù)訪問(wèn)更快 ，因?yàn)榫鄞厮饕龑⑺饕蛿?shù)據(jù)保存在同一個(gè)B+樹(shù)中，因此從聚簇索引中獲取數(shù)據(jù)比非聚簇索引更快
• 聚簇索引對(duì)于主鍵的 排序查找 和 范圍查找 速度非?？?/li>
• 按照聚簇索引排列順序，查詢(xún)顯示一定范圍數(shù)據(jù)的時(shí)候，由于數(shù)據(jù)都是緊密相連，數(shù)據(jù)庫(kù)不用從多個(gè)數(shù)據(jù)塊中提取數(shù)據(jù)，所以 節(jié)省了大量的io操作 。

3、缺點(diǎn)

• 插入速度嚴(yán)重依賴(lài)于插入順序 ，按照主鍵的順序插入是最快的方式，否則將會(huì)出現(xiàn)頁(yè)分裂，嚴(yán)重影響性能。因此，對(duì)于InnoDB表，我們一般都會(huì)定義一個(gè)自增的ID列為主鍵
• 更新主鍵的代價(jià)很高 ，因?yàn)閷?huì)導(dǎo)致被更新的行移動(dòng)。因此，對(duì)于InnoDB表，我們一般定義主鍵為不可更新
• 二級(jí)索引訪問(wèn)需要兩次索引查找 ，第一次找到主鍵值，第二次根據(jù)主鍵值找到行數(shù)據(jù)

2.2、二級(jí)索引（又叫輔助索引、非聚簇索引）

二級(jí)索引我們并不是將主鍵作為索引，而是用非主鍵進(jìn)行索引。每一行的記錄包括非主鍵的索引和主鍵。

因此我們利用二級(jí)索引去查找某個(gè)完整的記錄，需要兩步操作，第一步，通過(guò)二級(jí)索引去查找主鍵，第二步，通過(guò)聚簇索引去查找記錄。
這就是回表操作，所以查找一條記錄我們需要查找兩棵B+索引樹(shù)！

面試問(wèn)題，為什么需要一次回表操作了？直接把完整的用戶(hù)記錄放到葉子節(jié)點(diǎn)不OK嗎？
因?yàn)樵跀?shù)據(jù)庫(kù)中不會(huì)只設(shè)置一個(gè)二級(jí)索引，如果每個(gè)二級(jí)索引的葉子結(jié)點(diǎn)都放置完整的用戶(hù)數(shù)據(jù)（每個(gè)用戶(hù)的數(shù)據(jù)可能有幾百萬(wàn)個(gè)），會(huì)極大的加大存儲(chǔ)空間的開(kāi)銷(xiāo)

2.3、聯(lián)合索引

我們也可以同時(shí)以多個(gè)列的大小作為排序規(guī)則，也就是同時(shí)為多個(gè)列建立索引，比方說(shuō)我們想讓B+樹(shù)按照 c2和c3列 的大小進(jìn)行排序，這個(gè)包含兩層含義：

• 先把各個(gè)記錄和頁(yè)按照c2列進(jìn)行排序。
• 在記錄的c2列相同的情況下，采用c3列進(jìn)行排序

注意一點(diǎn)，以c2和c3列的大小為排序規(guī)則建立的B+樹(shù)稱(chēng)為 聯(lián)合索引 ，本質(zhì)上也是一個(gè)二級(jí)索引。它的意思與分別為c2和c3列分別建立索引的表述是不同的，不同點(diǎn)如下：

• 建立 聯(lián)合索引 只會(huì)建立如上圖一樣的1棵B+樹(shù)。
• 為c2和c3列分別建立索引會(huì)分別以c2和c3列的大小為排序規(guī)則建立2棵B+樹(shù)。

三、索引的數(shù)據(jù)結(jié)構(gòu)

1、全表遍歷

復(fù)雜度是O(n)的，效率很差

2、Hash結(jié)構(gòu)

Hash結(jié)構(gòu)的效率是很高的，時(shí)間復(fù)雜度可以為O（1）

那為什么Hash結(jié)構(gòu)的效率這么搞，那為什么索引的數(shù)據(jù)結(jié)構(gòu)設(shè)計(jì)成樹(shù)形了？有四點(diǎn)原因

Hash索引適用存儲(chǔ)引擎如表所示：

雖然在InnoDB存儲(chǔ)引擎中，不支持Hash索引，但是卻提供了自適應(yīng)Hash索引(Adaptive Hash Index)。

那什么情況下使用自適應(yīng)Hash索引了？

如果某個(gè)數(shù)據(jù)經(jīng)常被訪問(wèn)，當(dāng)滿(mǎn)足一定條件的時(shí)候，就會(huì)將這個(gè)數(shù)據(jù)頁(yè)的地址存放到hash表中，這樣在下次查詢(xún)的時(shí)候，就可以找到這個(gè)頁(yè)面所在的位置。這樣B+樹(shù)也具備了Hash索引的優(yōu)點(diǎn)。

采用自適應(yīng) Hash 索引目的是方便根據(jù) SQL 的查詢(xún)條件加速定位到葉子節(jié)點(diǎn)，特別是當(dāng) B+ 樹(shù)比較深的時(shí)候，通過(guò)自適應(yīng) Hash 索引可以明顯提高數(shù)據(jù)的檢索效率。

我們可以通過(guò)innodb_adaptive_hash_index變量來(lái)查看是否開(kāi)啟了自適應(yīng) Hash，比如：

show variables like '%adaptive_hash_index';

3、二插搜索樹(shù)

二插搜索樹(shù)在某種情況下，時(shí)間復(fù)雜度會(huì)變成O(n)

為了提高查詢(xún)效率，就需要 減少磁盤(pán)IO數(shù) 。為了減少磁盤(pán)IO的次數(shù)，就需要盡量 降低樹(shù)的高度 ，需要把原來(lái)“瘦高”的樹(shù)結(jié)構(gòu)變的“矮胖”，樹(shù)的每層的分叉越多越好。

4、AVL樹(shù)

5、 B樹(shù)

一個(gè) M 階的 B 樹(shù)（M>2）有以下的特性：

（1）根節(jié)點(diǎn)的兒子數(shù)的范圍是 [2,M]。
（2）每個(gè)中間節(jié)點(diǎn)包含 k-1 個(gè)關(guān)鍵字和 k 個(gè)孩子，孩子的數(shù)量 = 關(guān)鍵字的數(shù)量 +1，k 的取值范圍為[ceil(M/2), M]。
（3）葉子節(jié)點(diǎn)包括 k-1 個(gè)關(guān)鍵字（葉子節(jié)點(diǎn)沒(méi)有孩子），k 的取值范圍為 [ceil(M/2), M]。
（4）假設(shè)中間節(jié)點(diǎn)節(jié)點(diǎn)的關(guān)鍵字為：Key[1], Key[2], …, Key[k-1]，且關(guān)鍵字按照升序排序，即 Key[i]
<Key[i+1]。此時(shí) k-1 個(gè)關(guān)鍵字相當(dāng)于劃分了 k 個(gè)范圍，也就是對(duì)應(yīng)著 k 個(gè)指針，即為：P[1], P[2], >…,P[k]，其中 P[1] 指向關(guān)鍵字小于 Key[1] 的子樹(shù)，P[i] 指向關(guān)鍵字屬于 (Key[i-1], Key[i]) 的子樹(shù)，P[k]>指向關(guān)鍵字大于 Key[k-1] 的子樹(shù)。
（4）所有葉子節(jié)點(diǎn)位于同一層。

上面那張圖所表示的 B 樹(shù)就是一棵 3 階的 B 樹(shù)。我們可以看下磁盤(pán)塊 2，里面的關(guān)鍵字為（8，12），它有 3 個(gè)孩子 (3，5)，(9，10) 和 (13，15)，你能看到 (3，5) 小于 8，(9，10) 在 8 和 12 之間，而 (13，15)大于 12，剛好符合剛才我們給出的特征。

然后我們來(lái)看下如何用 B 樹(shù)進(jìn)行查找。假設(shè)我們想要 查找的關(guān)鍵字是 9 ，那么步驟可以分為以下幾步

• （1）我們與根節(jié)點(diǎn)的關(guān)鍵字 (17，35）進(jìn)行比較，9 小于 17 那么得到指針 P1；
• （2）按照指針 P1 找到磁盤(pán)塊 2，關(guān)鍵字為（8，12），因?yàn)?9 在 8 和 12 之間，所以我們得到指針 P2；
• （3）按照指針 P2 找到磁盤(pán)塊 6，關(guān)鍵字為（9，10），然后我們找到了關(guān)鍵字 9。

你能看出來(lái)在 B 樹(shù)的搜索過(guò)程中，我們比較的次數(shù)并不少，但如果把數(shù)據(jù)讀取出來(lái)然后在內(nèi)存中進(jìn)行比較，這個(gè)時(shí)間就是可以忽略不計(jì)的。而讀取磁盤(pán)塊本身需要進(jìn)行 I/O 操作，消耗的時(shí)間比在內(nèi)存中進(jìn)行比較所需要的時(shí)間要多，是數(shù)據(jù)查找用時(shí)的重要因素。 B 樹(shù)相比于平衡二叉樹(shù)來(lái)說(shuō)磁盤(pán) I/O 操作要少，在數(shù)據(jù)查詢(xún)中比平衡二叉樹(shù)效率要高。所以 只要樹(shù)的高度足夠低，IO次數(shù)足夠少，就可以提高查詢(xún)性能

6、B+樹(shù)

1、B+樹(shù)和B樹(shù)的差異

• B+樹(shù)有 k 個(gè)孩子的節(jié)點(diǎn)就有 k 個(gè)關(guān)鍵字。也就是孩子數(shù)量 = 關(guān)鍵字?jǐn)?shù)，而 B 樹(shù)中，孩子數(shù)量 = 關(guān)鍵字?jǐn)?shù)+1。
• B+樹(shù)中，非葉子節(jié)點(diǎn)的關(guān)鍵字也會(huì)同時(shí)存在在子節(jié)點(diǎn)中，并且是在子節(jié)點(diǎn)中所有關(guān)鍵字的最大（或最小）。
• B+樹(shù)中，非葉子節(jié)點(diǎn)僅用于索引，不保存數(shù)據(jù)記錄，跟記錄有關(guān)的信息都放在葉子節(jié)點(diǎn)中。而 B 樹(shù)中， 非葉子節(jié)點(diǎn)既保存索引，也保存數(shù)據(jù)記錄 。
• 所有關(guān)鍵字都在葉子節(jié)點(diǎn)出現(xiàn)，葉子節(jié)點(diǎn)構(gòu)成一個(gè)有序鏈表，而且葉子節(jié)點(diǎn)本身按照關(guān)鍵字的大小從小到大順序鏈接。

2、B+樹(shù)就比B樹(shù)好嗎？

B 樹(shù)和 B+ 樹(shù)都可以作為索引的數(shù)據(jù)結(jié)構(gòu)，在 MySQL 中采用的是 B+ 樹(shù)。但B樹(shù)和B+樹(shù)各有自己的應(yīng)用場(chǎng)景，不能說(shuō)B+樹(shù)完全比B樹(shù)好，反之亦然。

3 、思考題：為了減少I(mǎi)O，索引樹(shù)會(huì)一次性加載嗎？

不會(huì)，因?yàn)樗饕龝?huì)占用空間，大量的索引可能會(huì)超出1g多的大小，所以不會(huì)一次性加載

4、思考題：B+樹(shù)的存儲(chǔ)能力如何？為何說(shuō)一般查找行記錄，最多只需1~3次磁盤(pán)IO

儲(chǔ)存能力很強(qiáng)，倘若一開(kāi)始的根頁(yè)可以存放100條數(shù)據(jù)條目，那如果頁(yè)目錄可以存放1000條，那二級(jí)存放的量就1001000，三級(jí)就是10010001000,4級(jí)就是100100010001000，那為什么最多只需要加載最大3次呢，因?yàn)楦?yè)的數(shù)據(jù)在一開(kāi)始已經(jīng)加載了所有無(wú)需加載，那么就算最大加載4級(jí)，那也就需要加載最大3次

5、思考題：為什么說(shuō)B+樹(shù)比B-樹(shù)更適合實(shí)際應(yīng)用中操作系統(tǒng)的文件索引和數(shù)據(jù)庫(kù)索引？

因?yàn)锽+樹(shù)查詢(xún)更為穩(wěn)定，且適合范圍的快速查找

6、思考題：Hash 索引與 B+ 樹(shù)索引的區(qū)別

HASH索引的范圍查找效率比B+樹(shù)索引效率低很多，且不支持聯(lián)合索引

7、思考題：Hash 索引與 B+ 樹(shù)索引是在建索引的時(shí)候手動(dòng)指定的嗎？

不是的，是一開(kāi)始我們創(chuàng)建表的時(shí)候，每次插入數(shù)據(jù)，他背后都會(huì)去維護(hù)對(duì)應(yīng)索引，如果又新加的二級(jí)索引才會(huì)再創(chuàng)建索引

7、R樹(shù)

R-Tree在MySQL很少使用，僅支持 geometry數(shù)據(jù)類(lèi)型 ，支持該類(lèi)型的存儲(chǔ)引擎只有myisam、bdb、innodb、ndb、archive幾種。

舉個(gè)R樹(shù)在現(xiàn)實(shí)領(lǐng)域中能夠解決的例子：查找20英里以?xún)?nèi)所有的餐廳。如果沒(méi)有R樹(shù)你會(huì)怎么解決？一般情況下我們會(huì)把餐廳的坐標(biāo)(x,y)分為兩個(gè)字段存放在數(shù)據(jù)庫(kù)中，一個(gè)字段記錄經(jīng)度，另一個(gè)字段記錄緯度。這樣的話我們就需要遍歷所有的餐廳獲取其位置信息，然后計(jì)算是否滿(mǎn)足要求。如果一個(gè)地區(qū)有100家餐廳的話，我們就要進(jìn)行100次位置計(jì)算操作了，如果應(yīng)用到谷歌、百度地圖這種超大數(shù)據(jù)庫(kù)中，這種方法便必定不可行了。R樹(shù)就很好的解決了這種高維空間搜索問(wèn)題。它把B樹(shù)的思想很好的擴(kuò)展到了多維空間，采用了B樹(shù)分割空間的思想，并在添加、刪除操作時(shí)采用合并、分解結(jié)點(diǎn)的方法，保證樹(shù)的平衡性。因此，R樹(shù)就是一棵用來(lái)存儲(chǔ)高維數(shù)據(jù)的平衡樹(shù) 。相對(duì)于B-Tree，R-Tree的優(yōu)勢(shì)在于范圍查找

文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-621507.html

四、索引的適用和不適用場(chǎng)景

1、適用場(chǎng)景

• 主鍵自動(dòng)建立唯一索引
• 頻繁作為查詢(xún)的條件的字段應(yīng)該創(chuàng)建索引
• 查詢(xún)中與其他表關(guān)聯(lián)的字段
• 頻繁更新的字段不適合創(chuàng)建索引
• 查詢(xún)中排序的字段，排序字段若通過(guò)索引去訪問(wèn)將大大提高排序的速度
• 查詢(xún)中統(tǒng)計(jì)或者分組字段

2、不適用場(chǎng)景

• Where條件里用不到的字段不創(chuàng)建索引
• 表記錄太少
• 經(jīng)常增刪改的表
• 數(shù)據(jù)重復(fù)且分布平均的表字段

到了這里，關(guān)于MySQL索引的數(shù)據(jù)結(jié)構(gòu)的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！