主鍵索引就是聚集索引?MySQL 索引類型大梳理
1. 按照功能劃分
按照功能來(lái)劃分,索引主要有四種:
- 普通索引
- 唯一性索引
- 主鍵索引
- 全文索引
普通索引就是最最基礎(chǔ)的索引,這種索引沒(méi)有任何的約束作用,它存在的主要意義就是提高查詢效率。
普通索引創(chuàng)建方式如下:
CREATE TABLE `user` (
`id` int(11) unsigned NOT NULL AUTO_INCREMENT,
`name` varchar(64) DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `name` (`name`)
) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8mb4;
name 字段就是一個(gè)普通索引(括號(hào)外面的是索引名,里邊的是索引的字段)。
唯一性索引則在普通索引的基礎(chǔ)上增加了數(shù)據(jù)唯一性的約束,一張表中可以同時(shí)存在多個(gè)唯一性索引,唯一性索引創(chuàng)建方式如下:
CREATE TABLE `user` (
`id` int(11) unsigned NOT NULL AUTO_INCREMENT,
`name` varchar(64) DEFAULT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `name` (`name`)
) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8mb4;
name 字段就是唯一性索引。
主鍵索引則是在唯一性索引的基礎(chǔ)上又增加了不為空的約束(換言之,添加了唯一性索引的字段,是可以包含 NULL 值的),即 NOT NULL+UNIQUE,一張表里最多只有一個(gè)主鍵索引,當(dāng)然一個(gè)主鍵索引中可以包含多個(gè)字段。
前面兩個(gè)例子中都有主鍵索引的創(chuàng)建方式,我這里就不再列舉了。
全文索引其實(shí)我們很少在 MySQL 中用,如果項(xiàng)目中有做全文索引的需求,一般可以通過(guò) Elasticsearch 或者 Solr 來(lái)做,目前比較流行的就是 Elasticsearch 了,松哥之前也錄過(guò)專門(mén)的視頻,公眾號(hào)后臺(tái)回復(fù) es 獲取教程鏈接。
全文索引在 MySQL 中支持的版本也需要大家留意一下:
- MySQL 5.6 以前的版本,只有 MyISAM 存儲(chǔ)引擎支持全文索引。
- MySQL 5.6 及以后的版本,MyISAM 和 InnoDB 存儲(chǔ)引擎均支持全文索引。
創(chuàng)建全文索引對(duì)字段類型也有要求,只有字段的數(shù)據(jù)類型為 CHAR、VARCHAR 以及 TEXT 等才可以建立全文索引。
MySQL 的全文索引最開(kāi)始只支持英文,因?yàn)橛⑽姆衷~比較方便;中文分詞就比較麻煩,所以最早的 MySQL 全文索引是不支持中文的。從 MySQL5.7.6 版本開(kāi)始,引入了 ngram 全文分析器來(lái)解決分詞問(wèn)題,并且這個(gè)分詞器對(duì) MyISAM 和 InnoDB 引擎都有效。
不過(guò) MySQL 的全文索引并不好用,有這方面的需求還是直接上 Es 吧。
全文索引的創(chuàng)建方式如下:
CREATE TABLE `user` (
`id` int(11) unsigned NOT NULL AUTO_INCREMENT,
`name` varchar(64) DEFAULT NULL,
PRIMARY KEY (`id`),
FULLTEXT KEY `name` (`name`)
) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8mb4;
name 字段就是全文索引。
2. 按照物理實(shí)現(xiàn)劃分
按照物理實(shí)現(xiàn)方式,索引可以分為兩大類:
- 聚集索引(有的人也稱之為“聚簇索引”)
- 非聚集索引(有的人也稱之為“非聚簇索引”)
2.1 聚集索引
聚集索引在存儲(chǔ)的時(shí)候,可以按照主鍵(不是必須,看情況)來(lái)排序存儲(chǔ)數(shù)據(jù),B+Tree 的葉子結(jié)點(diǎn)就是完整的數(shù)據(jù)行,查找的時(shí)候,找到了主鍵也就找到了完整的數(shù)據(jù)行。
如下圖,在聚集索引中,葉子結(jié)點(diǎn)保存了每一行的數(shù)據(jù)。
在聚集索引里,表中數(shù)據(jù)行按索引的排序方式進(jìn)行存儲(chǔ),對(duì)查找行很有效。只有當(dāng)表包含聚集索引時(shí),表內(nèi)的數(shù)據(jù)行才會(huì)按找索引列的值在磁盤(pán)上進(jìn)行物理排序和存儲(chǔ)。每張表只能有一個(gè)聚集索引,原因很簡(jiǎn)單,因?yàn)閿?shù)據(jù)行本身只能按一個(gè)順序存儲(chǔ)。
當(dāng)我們基于 InnoDB 引擎創(chuàng)建一張表的時(shí)候,都會(huì)創(chuàng)建一個(gè)聚集索引,每張表都有唯一的聚集索引:
- 如果這張表定義了主鍵索引,那么這個(gè)主鍵索引就作為聚集索引。
- 如果這張表沒(méi)有定義主鍵索引,那么該表的第一個(gè)唯一非空索引作為聚集索引。
- 如果這張表也沒(méi)有唯一非空索引,那么 InnoDB 內(nèi)部會(huì)生成一個(gè)隱藏的主鍵作為聚集索引,這個(gè)隱藏的主鍵是一個(gè) 6 個(gè)字節(jié)的列,該列的值會(huì)隨著數(shù)據(jù)的插入自增。
基于以上描述大家可以看到,主鍵索引和聚集索引并不是一回事,切勿混淆!
聚集索引最主要的優(yōu)勢(shì)就是查詢快。如果要查詢完整的數(shù)據(jù)行,使用非聚集索引往往需要回表才能實(shí)現(xiàn),而使用聚集索引則能一步到位。
不過(guò)聚集索引也有一些劣勢(shì):
- 聚集索引可以減少磁盤(pán) IO 的次數(shù),這在傳統(tǒng)的機(jī)械硬盤(pán)中是很有優(yōu)勢(shì)的,不過(guò)要是固態(tài)硬盤(pán)或者內(nèi)存(有時(shí)候?yàn)榱颂岣卟僮餍?,?shù)據(jù)庫(kù)服務(wù)器會(huì)整一個(gè)比較大的內(nèi)存),這個(gè)優(yōu)勢(shì)就不明顯了。
- 聚集索引在插入的時(shí)候,最好是主鍵自增,自增主鍵插入的時(shí)候比較快,直接插入即可,不會(huì)涉及到葉子節(jié)點(diǎn)分裂等問(wèn)題(不需要挪動(dòng)其他記錄);而其他非自增主鍵插入的時(shí)候,可能要插入到兩個(gè)已有的數(shù)據(jù)中間,就有可能導(dǎo)致葉子節(jié)點(diǎn)分裂等問(wèn)題,插入效率低(要挪動(dòng)其他記錄)。如果聚集索引在插入的時(shí)候不是自增主鍵,插入效率就會(huì)比較低。
2.2 非聚集索引
非聚集索引我們一般也稱為二級(jí)索引或者輔助索引,對(duì)于非聚集索引,數(shù)據(jù)庫(kù)會(huì)有單獨(dú)的存儲(chǔ)空間來(lái)存放。非聚集索引在查找的時(shí)候要經(jīng)過(guò)兩個(gè)步驟,例如執(zhí)行 select * from user where username='javaboy'(假設(shè) username 字段是非聚集索引),那么此時(shí)需要先搜索 username 這一列索引的 B+Tree,這個(gè) B+Tree 的葉子結(jié)點(diǎn)存儲(chǔ)的不是完整的數(shù)據(jù)行,而是主鍵值,當(dāng)我們搜索完成后得到主鍵的值,然后拿著主鍵值再去搜索主鍵索引的 B+Tree,就可以獲取到一行完整的數(shù)據(jù)。
所以如果我們?cè)诓樵冎杏玫搅朔蔷奂饕?,那么就?huì)搜索兩棵 B+Tree,第一次搜索 B+Tree 拿到主鍵值后再去搜索聚集索引的 B+Tree,這個(gè)過(guò)程就是所謂的回表。
一張表只能有一個(gè)聚集索引,但可以有多個(gè)非聚集索引。使用聚集索引的時(shí)候,數(shù)據(jù)的查詢效率高,但如果對(duì)數(shù)據(jù)進(jìn)行插入,刪除,更新等操作,效率會(huì)比非聚集索引低。
3. 小結(jié)
總的來(lái)說(shuō),數(shù)據(jù)庫(kù)索引可以按照兩種思路來(lái)分類:按照功能分和按照存儲(chǔ)方式分。
按照功能分,可以分四種:
- 普通索引
- 唯一性索引
- 主鍵索引
- 全文索引
按照存儲(chǔ)方式分,可以分兩種:
- 聚集索引
- 非聚集索引
每種之間有區(qū)別又有聯(lián)系,希望上文能為大家解惑。