聚簇索引：是對(duì)磁盤(pán)上實(shí)際數(shù)據(jù)重新組織以按指定的一個(gè)或多個(gè)列的值排序的算法。特點(diǎn)是存儲(chǔ)數(shù)據(jù)的順序和索引順序一致，且一個(gè)表只能有一個(gè)聚簇索引，因?yàn)槲锢泶鎯?chǔ)只能有一個(gè)順序。主鍵索引一般都是聚簇索引

非聚簇索引：表數(shù)據(jù)存儲(chǔ)順序與索引順序無(wú)關(guān)。對(duì)于非聚簇索引，葉結(jié)點(diǎn)包含索引字段值及指向數(shù)據(jù)頁(yè)數(shù)據(jù)行的邏輯指針，其行數(shù)量與數(shù)據(jù)表行數(shù)據(jù)量一致。非聚簇索引記錄的物理順序與邏輯順序沒(méi)有必然的聯(lián)系，與數(shù)據(jù)的存儲(chǔ)物理結(jié)構(gòu)沒(méi)有關(guān)系；一個(gè)表對(duì)應(yīng)的非聚簇索引可以有多條，根據(jù)不同列的約束可以建立不同要求的非聚簇索引；

一般情況下主鍵會(huì)默認(rèn)創(chuàng)建聚簇索引，且一張表只允許存在一個(gè)聚簇索引。因?yàn)槲锢泶鎯?chǔ)只能有一個(gè)順序。

聚簇索引的葉子節(jié)點(diǎn)就是數(shù)據(jù)節(jié)點(diǎn)（Innodb的B+樹(shù)的主鍵對(duì)應(yīng)的數(shù)據(jù)節(jié)點(diǎn)），而非聚簇索引的葉子節(jié)點(diǎn)仍然是索引節(jié)點(diǎn)，只不過(guò)有指向?qū)?yīng)數(shù)據(jù)塊的指針。

聚簇索引主鍵的插入速度要比非聚簇索引主鍵的插入速度慢很多。

相比之下，聚簇索引適合排序，非聚簇索引不適合用在排序的場(chǎng)合。因?yàn)榫鄞厮饕旧硪呀?jīng)是按照物理順序放置的，排序很快。非聚簇索引則沒(méi)有按序存放，需要額外消耗資源來(lái)排序。

建立聚簇索引的語(yǔ)句：

CREATE CLUSTER INDEX index_name ON table_name(column_name1,...);

全文索引（也稱(chēng)全文檢索）是目前搜索引擎使用的一種關(guān)鍵技術(shù)。它能夠利用【分詞技術(shù)】等多種算法智能分析出文本文字中關(guān)鍵詞的頻率和重要性，然后按照一定的算法規(guī)則智能地篩選出我們想要的搜索結(jié)果。

select * from 表名 where?標(biāo)題 like '%xxx%' or 內(nèi)容?like '%xxx%' or 作者?like '%xxx%';

這種搜索效率無(wú)比底下

全文索引是為了使得“關(guān)鍵詞搜索”功能更加的高效能。

我們有這么一張數(shù)據(jù)表：?

文章id 文章標(biāo)題 文章內(nèi)容

1 超級(jí)塞亞人 ?我是超級(jí)塞亞人我喜歡吃蘋(píng)果，我不是233大國(guó)的人，也不是地球人

2 我233大國(guó)威武，我233大國(guó)13億人，我233大國(guó)

3 我喜歡游泳 游泳有很多好方法

4 動(dòng)畫(huà)片 我兒子喜歡看動(dòng)畫(huà)片，尤其是七龍珠，因?yàn)槔锩嬗腥麃喨?#xff0c;而且塞亞人喜歡吃蘋(píng)果,他們不是地球人

5 運(yùn)動(dòng) 我喜歡運(yùn)動(dòng)，喜歡跑步，喜歡游泳，喜歡健身，喜歡xxoo

6 打炮 我是一個(gè)二戰(zhàn)的老兵，這是我的回憶錄，我最幸福的時(shí)光就是在233大國(guó)吃著蘋(píng)果打炮

7 。。。 ?

8 。。。 ?

9 。。。 ?

然后，根據(jù)以上的文章內(nèi)容，如果建立了一個(gè)索引文件（這里忽略索引文件的數(shù)據(jù)結(jié)構(gòu)，僅僅以一種易于理解的方式呈現(xiàn)）：?

關(guān)鍵詞 ? 文章id

塞亞人 ? ?1,4

蘋(píng)果 ? ? ?1,4,6

233大國(guó) ? ? ?1,2,6

地球 ? ? ? ?1,4

游泳 ? ? ? ?3,5

七龍珠 ? ? ?4

喜歡 ? ? 1,4,5,6 ??

那么當(dāng)我想搜索 ?“塞亞人”的時(shí)候，這個(gè)索引文件直接告訴我在文章id為1和4的文章里有這個(gè)詞。?

這個(gè)索引文件就是“全文索引”。

如何使用全文索引和分詞的方式來(lái)幫助優(yōu)化你的搜索呢？

需要工作的程序：索引程序，分詞程序，數(shù)據(jù)庫(kù)。?

工作原理：?

1、索引程序從數(shù)據(jù)庫(kù)讀取數(shù)據(jù)，比如上面例子中的數(shù)據(jù)表，索引程序通過(guò)sql語(yǔ)句：select 文章id,文章標(biāo)題，文章內(nèi)容 from 文章表.獲得文章的相關(guān)數(shù)據(jù)?

2、索引程序?qū)π枰饕膬?nèi)容進(jìn)行“分詞”，而這里的分詞就是調(diào)用分詞程序啦！?

3、索引程序?qū)Ψ趾迷~的一個(gè)個(gè)詞條加入索引文件。

在你寫(xiě)的代碼里，原來(lái)到數(shù)據(jù)庫(kù)－－－－like %xxx%－－－－－的語(yǔ)句就變成了到索引文件里去查找，從而找到相應(yīng)的數(shù)據(jù)（這點(diǎn)相信你已經(jīng)理解啦！）

創(chuàng)建全文索引的兩種方法：

1.在建表語(yǔ)句中

2.在已知表中

ALTER TABLE article ADD FULLTEXT INDEX fulltext_article(title,content);

具體如何使用全文索引呢？

不用全文索引時(shí)的寫(xiě)法：SELECT * FROM article WHERE content LIKE ‘%查詢(xún)字符串%’;

使用全文索引：SELECT * FROM article WHERE MATCH(title,content) AGAINST (‘查詢(xún)字符串’);

注意：

1、MySql自帶的全文索引只能對(duì)英文進(jìn)行全文檢索，目前無(wú)法對(duì)中文進(jìn)行全文檢索。如果需要對(duì)包含中文在內(nèi)的文本數(shù)據(jù)進(jìn)行全文檢索，我們需要采用Sphinx（斯芬克斯）/Coreseek技術(shù)來(lái)處理中文。

2、使用MySql自帶的全文索引時(shí)，如果查詢(xún)字符串的長(zhǎng)度過(guò)短將無(wú)法得到期望的搜索結(jié)果。MySql全文索引所能找到的詞默認(rèn)最小長(zhǎng)度為4個(gè)字符。另外，如果查詢(xún)的字符串包含停止詞，那么該停止詞將會(huì)被忽略。

3、如果可能，請(qǐng)盡量先創(chuàng)建表并插入所有數(shù)據(jù)后再創(chuàng)建全文索引，而不要在創(chuàng)建表時(shí)就直接創(chuàng)建全文索引，因?yàn)榍罢弑群笳叩娜乃饕室摺?/p>

需要：

1).主鍵自動(dòng)建立唯一索引
2).頻繁作為查詢(xún)條件的字段應(yīng)該創(chuàng)建索引
3).查詢(xún)中與其它表關(guān)聯(lián)的字段，外鍵關(guān)系建立索引
4).單鍵/組合索引的選擇問(wèn)題(在高并發(fā)下傾向創(chuàng)建組合索引)
5).查詢(xún)中排序的字段，排序字段若通過(guò)索引去訪(fǎng)問(wèn)將大大提高排序速度
6).查詢(xún)中統(tǒng)計(jì)或者分組字段

不需要：

1).表記錄太少
2).經(jīng)常增刪改的表(因?yàn)椴粌H要保存數(shù)據(jù)，還要保存一下索引文件) 索引本來(lái)是一種事先在寫(xiě)的階段形成一定的數(shù)據(jù)結(jié)構(gòu)，從而使得在讀的階段效率較高的方式，但是如果一個(gè)字段是寫(xiě)多讀少，則會(huì)降低寫(xiě)的速度。
3).數(shù)據(jù)重復(fù)且分布平均的表字段（比如性別），因此應(yīng)該只為最經(jīng)常查詢(xún)和最經(jīng)常排序的數(shù)據(jù)列建立索引。

4).where條件里用不到的字段不創(chuàng)建索引

假設(shè)有條件語(yǔ)句A=a AND B=b，如果A和B是兩個(gè)單獨(dú)的索引，在AND條件下只有一個(gè)索引起作用，對(duì)于B則要逐個(gè)判斷，而如果使用組合索引(A, B)，只要遍歷一棵樹(shù)就可以了，大大增加了效率。但是對(duì)于A=a OR B=b，由于是 或 的關(guān)系，因而組合索引是不起作用的，此時(shí)可以使用單獨(dú)索引，這個(gè)時(shí)候，兩個(gè)索引可以同時(shí)起作用。

在建立聯(lián)合索引的時(shí)候，如何安排索引內(nèi)的字段順序？

? ? 評(píng)估標(biāo)準(zhǔn)是：索引的復(fù)用能力。因?yàn)榭梢灾С肿钭笄熬Y，所以當(dāng)已經(jīng)有了(a,b)這個(gè)聯(lián)合索引后，一般就不需要單獨(dú)在a上建立索引了。

? ? 因此，第一原則是，如果通過(guò)調(diào)整順序，可以少維護(hù)一個(gè)索引，那么這個(gè)順序往往就是需要優(yōu)先考慮采用的。

? ? 那么，如果既有聯(lián)合查詢(xún)，又有基于a、b各自的查詢(xún)呢？查詢(xún)條件里面只有b的語(yǔ)句，是無(wú)法使用(a,b)這個(gè)聯(lián)合索引的，這時(shí)候你不得不維護(hù)另外一個(gè)索引，也就是說(shuō)你需要同時(shí)維護(hù)(a,b)、(b) 這兩個(gè)索引。

? ? 這時(shí)候，我們要考慮的原則就是空間了。也就是說(shuō)，如果b的大小是比較小的，如boolean、int類(lèi)型， 那么可以再多建立一個(gè)b索引

下面通過(guò)一個(gè)例子來(lái)加深理解

假設(shè)有這么一個(gè)表：

CREATE TABLE `geek` (
? `a` int(11) NOT NULL,
? `b` int(11) NOT NULL,
? `c` int(11) NOT NULL,
? `d` int(11) NOT NULL,
? PRIMARY KEY (`a`,`b`),
? KEY `c` (`c`),
? KEY `ca` (`c`,`a`),
? KEY `cb` (`c`,`b`)
) ENGINE=InnoDB;

有以下經(jīng)常使用的查詢(xún)語(yǔ)句
select * from geek where c=N order by a limit 1;
select * from geek where c=N order by b limit 1;

這里我們需要思考，ca與cb索引是否都是必要的？

? ? 索引 ca 的組織是先按c排序，再按a排序，同時(shí)記錄主鍵(b)，根據(jù)最左前綴原則，實(shí)際上，ca索引的功能同c索引的功能是差不多的，因此可以得出ca索引不是必要的

? ? 索引 cb 的組織是先按c排序，再按b排序，同時(shí)記錄主鍵(a)，因此該索引需要保留

假如有如下數(shù)據(jù)表：

對(duì)于表中每一行數(shù)據(jù)，索引中包含了last_name、first_name、dob列的值，下圖展示了索引是如何組織數(shù)據(jù)存儲(chǔ)的。

可以看到，索引首先根據(jù)第一個(gè)字段來(lái)排列順序，當(dāng)名字相同時(shí)，則根據(jù)第三個(gè)字段，即出生日期來(lái)排序，正是因?yàn)檫@個(gè)原因，才有了索引的“最左原則”。

在介紹這兩者的區(qū)別之前，我們先來(lái)介紹change buffer：

什么是change buffer？
? ? 當(dāng)需要更新一個(gè)記錄，就是要更新一個(gè)數(shù)據(jù)頁(yè)：

? ? 1. 如果數(shù)據(jù)頁(yè)在內(nèi)存中（buffer pool中時(shí)）就直接更新
? ? 2. 如果這個(gè)數(shù)據(jù)頁(yè)還沒(méi)有在內(nèi)存中（沒(méi)有在buffer pool中）。InooDB 會(huì)將這些更新操作緩存在 change buffer 中。在下次查詢(xún)需要訪(fǎng)問(wèn)這個(gè)數(shù)據(jù)頁(yè)時(shí)，將數(shù)據(jù)頁(yè)讀入內(nèi)存，然后執(zhí)行 change buffer 中與這個(gè)頁(yè)有關(guān)的操作
? ? 將 change buffer 中的操作應(yīng)用到原數(shù)據(jù)頁(yè)，得到最新結(jié)果的過(guò)程稱(chēng)為 merge，它可以避免大量的磁盤(pán)隨機(jī)訪(fǎng)問(wèn)I/O，merge的流程如下（并不會(huì)直接把數(shù)據(jù)寫(xiě)會(huì)磁盤(pán)）：

? ? ? ? ? ?1、從磁盤(pán)讀入數(shù)據(jù)頁(yè)到內(nèi)存（老版本的數(shù)據(jù)頁(yè)）；

? ? ? ? ? ?2、從change buffer里找出這個(gè)數(shù)據(jù)頁(yè)的change buffer 記錄(可能有多個(gè)），依次應(yīng)用，得到新版數(shù)據(jù)頁(yè)；

? ? ? ? ? ?3、寫(xiě)redo log。這個(gè)redo log包含了數(shù)據(jù)的變更和change buffer的變更。

? ? 而唯一索引的更新就不能使用 change buffer：對(duì)于唯一索引，所有的更新操作都要先判斷這個(gè)操作是否違反唯一性約束。那么必須將數(shù)據(jù)頁(yè)讀入內(nèi)存才能判斷。比如，要插入(4,400) 這個(gè)記錄，就要先判斷現(xiàn)在表中是否已經(jīng)存在 k=4 的記錄

? ? 都已經(jīng)讀入內(nèi)存中了，那直接更新內(nèi)存會(huì)更快，沒(méi)有必要使用change buffer了。

? ? 所以，只有普通索引才能使用change buffer，考慮使用普通索引還是唯一索引，如果能保證不會(huì)數(shù)據(jù)重復(fù)，那么最好使用普通索引（可以使用change buffer，且兩類(lèi)索引查詢(xún)能力沒(méi)有區(qū)別）

注意：不是所有的場(chǎng)景用change buffer都能加速：

? ? 1. 設(shè)想一個(gè)對(duì)于寫(xiě)多讀少的業(yè)務(wù)來(lái)說(shuō)，change buffer 記錄的變更越多越劃算，例如賬單類(lèi)日志類(lèi)

? ? 2. 反過(guò)來(lái)，一個(gè)業(yè)務(wù)的更新模式是寫(xiě)入之后馬上會(huì)做查詢(xún)，change buffer里的內(nèi)容不多，由于馬上做查詢(xún)要訪(fǎng)問(wèn)數(shù)據(jù)頁(yè)，這樣的io次數(shù)不會(huì)減少

如果某次寫(xiě)入使用了change buffer機(jī)制，之后主機(jī)異常重啟，是否會(huì)丟失change buffer和數(shù)據(jù)？

? ? 雖然寫(xiě)入時(shí)只更新了內(nèi)存，但是在事務(wù)提交的時(shí)候，change buffer的操作也會(huì)記錄到redo log，所以崩潰恢復(fù)的時(shí)候，change buffer也能找回來(lái)，即數(shù)據(jù)可以找回來(lái)。

所以普通索引和唯一索引，應(yīng)該怎么選擇？

? ? 查詢(xún)時(shí)：兩種索引查詢(xún)性能幾乎沒(méi)差別

? ? 更新時(shí)：大部分場(chǎng)景下，因?yàn)橛衏hange buffer的存在，普通索引的更新速度會(huì)比唯一索引的快（特別適用于寫(xiě)多讀少的場(chǎng)景）（如果所有的更新后面，都馬上伴隨著對(duì)這個(gè)記錄的查詢(xún)，那么應(yīng)該關(guān)閉change buffer）