你好，是我琉憶。

經(jīng)常跟數(shù)據(jù)打交道的你，有沒(méi)有去考慮過(guò)數(shù)據(jù)上百萬(wàn)，為什么它可以檢索那么快？

一說(shuō)到數(shù)據(jù)庫(kù)的檢索速度這么快，我想你一定想到了索引。

沒(méi)錯(cuò)，今天我們來(lái)簡(jiǎn)單聊聊索引，聊聊索引是什么，怎么使用，有什么優(yōu)缺點(diǎn)，它的工作原理，為什么它可以讓數(shù)據(jù)的檢索變得這么快。

01

索引是什么？

MYSQL官方對(duì)索引的定義為：索引(Index)是幫助MySQL高效獲取數(shù)據(jù)的數(shù)據(jù)結(jié)構(gòu)，所以說(shuō)索引的本質(zhì)是：數(shù)據(jù)結(jié)構(gòu)。

索引的目的在于提高查詢效率，可以類比字典、 火車站的車次表、圖書的目錄等 。

可以簡(jiǎn)單的理解為“排好序的快速查找數(shù)據(jù)結(jié)構(gòu)”，數(shù)據(jù)本身之外，數(shù)據(jù)庫(kù)還維護(hù)者一個(gè)滿足特定查找算法的數(shù)據(jù)結(jié)構(gòu)，這些數(shù)據(jù)結(jié)構(gòu)以某種方式引用(指向)數(shù)據(jù)，這樣就可以在這些數(shù)據(jù)結(jié)構(gòu)上實(shí)現(xiàn)高級(jí)查找算法。這種數(shù)據(jù)結(jié)構(gòu)，就是索引。下圖是一種可能的索引方式示例。左邊的數(shù)據(jù)表，一共有兩列七條記錄，最左邊的是數(shù)據(jù)記錄的物理地址。為了加快Col2的查找，可以維護(hù)一個(gè)右邊所示的二叉查找樹(shù)，每個(gè)節(jié)點(diǎn)分別包含索引鍵值，和一個(gè)指向?qū)?yīng)數(shù)據(jù)記錄物理地址的指針，這樣就可以運(yùn)用二叉查找在一定的復(fù)雜度內(nèi)獲取到對(duì)應(yīng)的數(shù)據(jù)，從而快速檢索出符合條件的記錄。

索引本身也很大，不可能全部存儲(chǔ)在內(nèi)存中，一般以索引文件的形式存儲(chǔ)在磁盤上

平常說(shuō)的索引，沒(méi)有特別指明的話，就是B+樹(shù)(多路搜索樹(shù)，不一定是二叉樹(shù))結(jié)構(gòu)組織的索引。其中聚集索引，次要索引，覆蓋索引，符合索引，前綴索引，唯一索引默認(rèn)都是使用B+樹(shù)索引，統(tǒng)稱索引。此外還有哈希索引等。

我們接下來(lái)講講索引的使用。

02

索引的使用

在創(chuàng)建表的時(shí)候添加索引

CREATE TABLE mytable( ID INT NOT NULL, username VARCHAR(16) NOT NULL, INDEX [indexName] (username(length)) );

在創(chuàng)建表以后添加索引

ALTER TABLE my_table ADD [UNIQUE] INDEX index_name(column_name);或者
CREATE INDEX index_name ON my_table(column_name);

刪除索引

DROP INDEX my_index ON tablename；

或者

ALTER TABLE table_name DROP INDEX index_name;

查看表中的索引

SHOW INDEX FROM tablename

查看查詢語(yǔ)句使用索引的情況

//explain 加查詢語(yǔ)句explain SELECT * FROM table_name WHERE column_1='123';

注意：

1、索引需要占用磁盤空間，因此在創(chuàng)建索引時(shí)要考慮到磁盤空間是否足夠

2、創(chuàng)建索引時(shí)需要對(duì)表加鎖，因此實(shí)際操作中需要在業(yè)務(wù)空閑期間進(jìn)行

選擇一樣?xùn)|西，就肯定有好有壞，我們說(shuō)說(shuō)索引的優(yōu)缺點(diǎn)。

03

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

優(yōu)勢(shì)：可以快速檢索，減少I/O次數(shù)，加快檢索速度；根據(jù)索引分組和排序，可以加快分組和排序；

劣勢(shì)：索引本身也是表，因此會(huì)占用存儲(chǔ)空間，一般來(lái)說(shuō)，索引表占用的空間的數(shù)據(jù)表的1.5倍；索引表的維護(hù)和創(chuàng)建需要時(shí)間成本，這個(gè)成本隨著數(shù)據(jù)量增大而增大；構(gòu)建索引會(huì)降低數(shù)據(jù)表的修改操作(刪除，添加，修改)的效率，因?yàn)樵谛薷臄?shù)據(jù)表的同時(shí)還需要修改索引表；

04

索引的實(shí)現(xiàn)原理

我們知道MySQL支持多種存儲(chǔ)引擎，而各種存儲(chǔ)引擎對(duì)索引的支持也各不相同，因此MySQL數(shù)據(jù)庫(kù)支持多種索引類型，如BTree索引，B+Tree索引，哈希索引，全文索引等等。

一、哈希索引

主要就是通過(guò)Hash算法(常見(jiàn)的Hash算法有直接定址法、平方取中法、折疊法、除數(shù)取余法、隨機(jī)數(shù)法)，將數(shù)據(jù)庫(kù)字段數(shù)據(jù)轉(zhuǎn)換成定長(zhǎng)的Hash值，與這條數(shù)據(jù)的行指針一并存入Hash表的對(duì)應(yīng)位置；如果發(fā)生Hash碰撞(兩個(gè)不同關(guān)鍵字的Hash值相同)，則在對(duì)應(yīng)Hash鍵下以鏈表形式存儲(chǔ)。檢索算法：在檢索查詢時(shí)，就再次對(duì)待查關(guān)鍵字再次執(zhí)行相同的Hash算法，得到Hash值，到對(duì)應(yīng)Hash表對(duì)應(yīng)位置取出數(shù)據(jù)即可，如果發(fā)生Hash碰撞，則需要在取值時(shí)進(jìn)行篩選。目前使用Hash索引的數(shù)據(jù)庫(kù)并不多，主要有Memory等。MySQL目前有Memory引擎和NDB引擎支持Hash索引。

二、全文索引

????(1)全文索引也是MyISAM的一種特殊索引類型，主要用于全文索引，InnoDB從MYSQL5.6版本提供對(duì)全文索引的支持。

????(2)它用于替代效率較低的LIKE模糊匹配操作，而且可以通過(guò)多字段組合的全文索引一次性全模糊匹配多個(gè)字段。

????(3)同樣使用B-Tree存放索引數(shù)據(jù)，但使用的是特定的算法，將字段數(shù)據(jù)分割后再進(jìn)行索引(一般每4個(gè)字節(jié)一次分割)，索引文件存儲(chǔ)的是分割前的索引字符串集合，與分割后的索引信息，對(duì)應(yīng)Btree結(jié)構(gòu)的節(jié)點(diǎn)存儲(chǔ)的是分割后的詞信息以及它在分割前的索引字符串集合中的位置。

三、B-Tree

????B-Tree是為磁盤等外存儲(chǔ)設(shè)備設(shè)計(jì)的一種平衡查找樹(shù)。

????系統(tǒng)從磁盤讀取數(shù)據(jù)到內(nèi)存時(shí)是以磁盤塊(block)為基本單位的，位于同一個(gè)磁盤塊中的數(shù)據(jù)會(huì)被一次性讀取出來(lái)，而不是需要什么取什么。

????InnoDB 存儲(chǔ)引擎中有頁(yè)(Page)的概念，頁(yè)是其磁盤管理的最小單位。InnoDB 存儲(chǔ)引擎中默認(rèn)每個(gè)頁(yè)的大小為16KB，可通過(guò)參數(shù) innodb_page_size 將頁(yè)的大小設(shè)置為 4K、8K、16K，在 MySQL 中可通過(guò)如下命令查看頁(yè)的大小：show variables like 'innodb_page_size';

????而系統(tǒng)一個(gè)磁盤塊的存儲(chǔ)空間往往沒(méi)有這么大，因此 InnoDB 每次申請(qǐng)磁盤空間時(shí)都會(huì)是若干地址連續(xù)磁盤塊來(lái)達(dá)到頁(yè)的大小 16KB。InnoDB 在把磁盤數(shù)據(jù)讀入到磁盤時(shí)會(huì)以頁(yè)為基本單位，在查詢數(shù)據(jù)時(shí)如果一個(gè)頁(yè)中的每條數(shù)據(jù)都能有助于定位數(shù)據(jù)記錄的位置，這將會(huì)減少磁盤I/O次數(shù)，提高查詢效率。

????B-Tree 結(jié)構(gòu)的數(shù)據(jù)可以讓系統(tǒng)高效的找到數(shù)據(jù)所在的磁盤塊。為了描述 B-Tree，首先定義一條記錄為一個(gè)二元組[key, data] ，key為記錄的鍵值，對(duì)應(yīng)表中的主鍵值，data 為一行記錄中除主鍵外的數(shù)據(jù)。對(duì)于不同的記錄，key值互不相同。

一棵m階的B-Tree有如下特性：

每個(gè)節(jié)點(diǎn)最多有m個(gè)孩子

除了根節(jié)點(diǎn)和葉子節(jié)點(diǎn)外，其它每個(gè)節(jié)點(diǎn)至少有Ceil(m/2)個(gè)孩子。

若根節(jié)點(diǎn)不是葉子節(jié)點(diǎn)，則至少有2個(gè)孩子

所有葉子節(jié)點(diǎn)都在同一層，且不包含其它關(guān)鍵字信息

每個(gè)非終端節(jié)點(diǎn)包含n個(gè)關(guān)鍵字信息(P0,P1,…Pn, k1,…kn)

關(guān)鍵字的個(gè)數(shù)n滿足：ceil(m/2)-1 <= n <= m-1

ki(i=1,…n)為關(guān)鍵字，且關(guān)鍵字升序排序

Pi(i=1,…n)為指向子樹(shù)根節(jié)點(diǎn)的指針。P(i-1)指向的子樹(shù)的所有節(jié)點(diǎn)關(guān)鍵字均小于ki，但都大于k(i-1)

B-Tree 中的每個(gè)節(jié)點(diǎn)根據(jù)實(shí)際情況可以包含大量的關(guān)鍵字信息和分支，如下圖所示為一個(gè) 3 階的 B-Tree：

每個(gè)節(jié)點(diǎn)占用一個(gè)盤塊的磁盤空間，一個(gè)節(jié)點(diǎn)上有兩個(gè)升序排序的關(guān)鍵字和三個(gè)指向子樹(shù)根節(jié)點(diǎn)的指針，指針存儲(chǔ)的是子節(jié)點(diǎn)所在磁盤塊的地址。兩個(gè)關(guān)鍵詞劃分成的三個(gè)范圍域?qū)?yīng)三個(gè)指針指向的子樹(shù)的數(shù)據(jù)的范圍域。以根節(jié)點(diǎn)為例，關(guān)鍵字為17和35，P1指針指向的子樹(shù)的數(shù)據(jù)范圍為小于17，P2指針指向的子樹(shù)的數(shù)據(jù)范圍為17~35，P3指針指向的子樹(shù)的數(shù)據(jù)范圍為大于35。

模擬查找關(guān)鍵字29個(gè)過(guò)程：

根據(jù)根節(jié)點(diǎn)找到磁盤塊1，讀入內(nèi)存。【磁盤I/O操作第1次】

比較關(guān)鍵字29在區(qū)間(17,35)，找到磁盤塊1的指針P2。

根據(jù)P2指針找到磁盤塊3，讀入內(nèi)存。【磁盤I/O操作第2次】

比較關(guān)鍵字29在區(qū)間(26,30)，找到磁盤塊3的指針P2。

根據(jù)P2指針找到磁盤塊8，讀入內(nèi)存。【磁盤I/O操作第3次】

在磁盤塊8中的關(guān)鍵字列表中找到關(guān)鍵字29。

分析上面過(guò)程，發(fā)現(xiàn)需要3次磁盤I/O操作，和3次內(nèi)存查找操作。由于內(nèi)存中的關(guān)鍵字是一個(gè)有序表結(jié)構(gòu)，可以利用二分法查找提高效率。而3次磁盤I/O操作是影響整個(gè)B-Tree查找效率的決定因素。B-Tree相對(duì)于AVLTree縮減了節(jié)點(diǎn)個(gè)數(shù)，使每次磁盤I/O取到內(nèi)存的數(shù)據(jù)都發(fā)揮了作用，從而提高了查詢效率。

四、B+Tree

B+Tree 是在 B-Tree 基礎(chǔ)上的一種優(yōu)化，使其更適合實(shí)現(xiàn)外存儲(chǔ)索引結(jié)構(gòu)，InnoDB 存儲(chǔ)引擎就是用 B+Tree 實(shí)現(xiàn)其索引結(jié)構(gòu)。

從上一節(jié)中的B-Tree結(jié)構(gòu)圖中可以看到每個(gè)節(jié)點(diǎn)中不僅包含數(shù)據(jù)的key值，還有data值。而每一個(gè)頁(yè)的存儲(chǔ)空間是有限的，如果data數(shù)據(jù)較大時(shí)將會(huì)導(dǎo)致每個(gè)節(jié)點(diǎn)(即一個(gè)頁(yè))能存儲(chǔ)的key的數(shù)量很小，當(dāng)存儲(chǔ)的數(shù)據(jù)量很大時(shí)同樣會(huì)導(dǎo)致B-Tree的深度較大，增大查詢時(shí)的磁盤I/O次數(shù)，進(jìn)而影響查詢效率。在B+Tree中，所有數(shù)據(jù)記錄節(jié)點(diǎn)都是按照鍵值大小順序存放在同一層的葉子節(jié)點(diǎn)上，而非葉子節(jié)點(diǎn)上只存儲(chǔ)key值信息，這樣可以大大加大每個(gè)節(jié)點(diǎn)存儲(chǔ)的key值數(shù)量，降低B+Tree的高度。

B+Tree相對(duì)于B-Tree有幾點(diǎn)不同：

非葉子節(jié)點(diǎn)只存儲(chǔ)鍵值信息；

所有葉子節(jié)點(diǎn)之間都有一個(gè)鏈指針；

數(shù)據(jù)記錄都存放在葉子節(jié)點(diǎn)中

將上一節(jié)中的B-Tree優(yōu)化，由于B+Tree的非葉子節(jié)點(diǎn)只存儲(chǔ)鍵值信息，假設(shè)每個(gè)磁盤塊能存儲(chǔ)4個(gè)鍵值及指針信息，則變成B+Tree后其結(jié)構(gòu)如下圖所示：

通常在B+Tree上有兩個(gè)頭指針，一個(gè)指向根節(jié)點(diǎn)，另一個(gè)指向關(guān)鍵字最小的葉子節(jié)點(diǎn)，而且所有葉子節(jié)點(diǎn)(即數(shù)據(jù)節(jié)點(diǎn))之間是一種鏈?zhǔn)江h(huán)結(jié)構(gòu)。因此可以對(duì)B+Tree進(jìn)行兩種查找運(yùn)算：一種是對(duì)于主鍵的范圍查找和分頁(yè)查找，另一種是從根節(jié)點(diǎn)開(kāi)始，進(jìn)行隨機(jī)查找。

可能上面例子中只有22條數(shù)據(jù)記錄，看不出B+Tree的優(yōu)點(diǎn)，下面做一個(gè)推算：

InnoDB存儲(chǔ)引擎中頁(yè)的大小為16KB，一般表的主鍵類型為INT(占用4個(gè)字節(jié))或BIGINT(占用8個(gè)字節(jié))，指針類型也一般為4或8個(gè)字節(jié)，也就是說(shuō)一個(gè)頁(yè)(B+Tree中的一個(gè)節(jié)點(diǎn))中大概存儲(chǔ)16KB/(8B+8B)=1K個(gè)鍵值(因?yàn)槭枪乐?#xff0c;為方便計(jì)算，這里的K取值為10^{3)。也就是說(shuō)一個(gè)深度為3的B+Tree索引可以維護(hù)10}3 * 10^3 * 10^3 = 10億 條記錄。

實(shí)際情況中每個(gè)節(jié)點(diǎn)可能不能填充滿，因此在數(shù)據(jù)庫(kù)中，B+Tree的高度一般都在2-4層。MySQL的InnoDB存儲(chǔ)引擎在設(shè)計(jì)時(shí)是將根節(jié)點(diǎn)常駐內(nèi)存的，也就是說(shuō)查找某一鍵值的行記錄時(shí)最多只需要1~3次磁盤I/O操作。

B+Tree性質(zhì)

通過(guò)上面的分析，我們知道IO次數(shù)取決于b+數(shù)的高度h，假設(shè)當(dāng)前數(shù)據(jù)表的數(shù)據(jù)為N，每個(gè)磁盤塊的數(shù)據(jù)項(xiàng)的數(shù)量是m，則有h=㏒(m+1)N，當(dāng)數(shù)據(jù)量N一定的情況下，m越大，h越小；而m = 磁盤塊的大小 / 數(shù)據(jù)項(xiàng)的大小，磁盤塊的大小也就是一個(gè)數(shù)據(jù)頁(yè)的大小，是固定的，如果數(shù)據(jù)項(xiàng)占的空間越小，數(shù)據(jù)項(xiàng)的數(shù)量越多，樹(shù)的高度越低。這就是為什么每個(gè)數(shù)據(jù)項(xiàng)，即索引字段要盡量的小，比如int占4字節(jié)，要比bigint8字節(jié)少一半。這也是為什么b+樹(shù)要求把真實(shí)的數(shù)據(jù)放到葉子節(jié)點(diǎn)而不是內(nèi)層節(jié)點(diǎn)，一旦放到內(nèi)層節(jié)點(diǎn)，磁盤塊的數(shù)據(jù)項(xiàng)會(huì)大幅度下降，導(dǎo)致樹(shù)增高。當(dāng)數(shù)據(jù)項(xiàng)等于1時(shí)將會(huì)退化成線性表。

當(dāng)b+樹(shù)的數(shù)據(jù)項(xiàng)是復(fù)合的數(shù)據(jù)結(jié)構(gòu)，比如(name,age,sex)的時(shí)候，b+數(shù)是按照從左到右的順序來(lái)建立搜索樹(shù)的，比如當(dāng)(張三,20,F)這樣的數(shù)據(jù)來(lái)檢索的時(shí)候，b+樹(shù)會(huì)優(yōu)先比較name來(lái)確定下一步的所搜方向，如果name相同再依次比較age和sex，最后得到檢索的數(shù)據(jù)；但當(dāng)(20,F)這樣的沒(méi)有name的數(shù)據(jù)來(lái)的時(shí)候，b+樹(shù)就不知道下一步該查哪個(gè)節(jié)點(diǎn)，因?yàn)榻⑺阉鳂?shù)的時(shí)候name就是第一個(gè)比較因子，必須要先根據(jù)name來(lái)搜索才能知道下一步去哪里查詢。比如當(dāng)(張三,F)這樣的數(shù)據(jù)來(lái)檢索時(shí)，b+樹(shù)可以用name來(lái)指定搜索方向，但下一個(gè)字段age的缺失，所以只能把名字等于張三的數(shù)據(jù)都找到，然后再匹配性別是F的數(shù)據(jù)了， 這個(gè)是非常重要的性質(zhì)，即索引的最左匹配特性。

后話

知道數(shù)據(jù)庫(kù)索引的原理更有利于我們表的設(shè)計(jì)，有利于提高數(shù)據(jù)庫(kù)SQL的編寫。這里只是簡(jiǎn)單的介紹了數(shù)據(jù)庫(kù)的檢索原理。更多的其他數(shù)據(jù)庫(kù)檢索知識(shí)可以去尋找學(xué)習(xí)。

如果覺(jué)得好看，就贊一個(gè)吧~

往期精選

• PHP面試常考內(nèi)容之Memcache和Redis(1)

• PHP面試常考內(nèi)容之Memcache和Redis(2)

• PHP面試之面向?qū)ο?1)

• PHP面試常考內(nèi)容之面向?qū)ο?2)

• PHP面試常考內(nèi)容之面向?qū)ο?3)

如有疑問(wèn)或想跟我交流，

可以加我的個(gè)人微信：leoyistar

關(guān)注琉憶編程庫(kù)，PHP面試資料都在這

點(diǎn)擊“好看”，就是對(duì)我最大的獎(jiǎng)賞

總結(jié)

以上是生活随笔為你收集整理的rac一节点时间比另一个节点快_数据库数据那么多为什么可以检索这么快？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。