摘要：通過(guò)增加額外的寫(xiě)操作和存儲(chǔ)空間來(lái)維護(hù)數(shù)據(jù)庫(kù)索引，可以提高從數(shù)據(jù)庫(kù)中讀取數(shù)據(jù)的速度。數(shù)據(jù)庫(kù)索引的實(shí)現(xiàn)常見(jiàn)的數(shù)據(jù)庫(kù)索引實(shí)現(xiàn)有平衡樹(shù)樹(shù)樹(shù)哈希樹(shù)，樹(shù)參考，中的索引數(shù)據(jù)庫(kù)支持多種索引類(lèi)型，如索引，哈希索引，全文索引等等。

數(shù)據(jù)庫(kù)索引是一種數(shù)據(jù)結(jié)構(gòu)。通過(guò)增加額外的寫(xiě)操作和存儲(chǔ)空間來(lái)維護(hù)數(shù)據(jù)庫(kù)索引，可以提高從數(shù)據(jù)庫(kù)中讀取數(shù)據(jù)的速度。通過(guò)索引，不需要搜索數(shù)據(jù)庫(kù)的每一條記錄，就可以快速地定位到特定的數(shù)據(jù)。索引可以建在在表中某一個(gè)字段或多個(gè)字段之上。總而言之：數(shù)據(jù)庫(kù)索引是一種數(shù)據(jù)結(jié)構(gòu)

用于支持快速地查找到數(shù)據(jù)

若沒(méi)有索引，通常需要遍歷所有記錄才能找到相應(yīng)地?cái)?shù)據(jù)（O(N)）;而通過(guò)索引，一般只需要O(log(N))次就可以定位到數(shù)據(jù)，提高了查找效率

管理數(shù)據(jù)庫(kù)約束

索引通常還會(huì)被用于管理數(shù)據(jù)庫(kù)約束，例如UNIQUE, EXCLUSION, PRIMARY KEY 和 FOREIGN KEY。當(dāng)一個(gè)索引被定義為UNIQUE時(shí)，數(shù)據(jù)庫(kù)同時(shí)創(chuàng)建一個(gè)隱式的約束。

聚集索引是指數(shù)據(jù)庫(kù)表行中數(shù)據(jù)的物理順序與鍵值的邏輯（索引）順序相同。一個(gè)表只能有一個(gè)聚集索引，因?yàn)橐粋€(gè)表的物理順序只有一種情況，所以，對(duì)應(yīng)的聚集索引只能有一個(gè)。如果某索引不是聚集索引，則表中的行物理順序與索引順序不匹配，與非聚集索引相比，聚集索引有著更快的檢索速度。如下圖，葉節(jié)點(diǎn)中直接包含了具體數(shù)據(jù)。

與聚集索引不同，非聚集索引的邏輯順序與磁盤(pán)上行的物理存儲(chǔ)順序不同。磁盤(pán)上的數(shù)據(jù)可以隨意分布，而通過(guò)非聚集索引，可以在邏輯上為數(shù)據(jù)排序。如下圖，葉節(jié)點(diǎn)沒(méi)有包含具體的數(shù)據(jù)，而是包含了一個(gè)指向具體數(shù)據(jù)的指針。

當(dāng)索引通過(guò)二叉樹(shù)的形式進(jìn)行描述時(shí)，我們可以這樣區(qū)分聚集與非聚集索引的區(qū)別：聚集索引的葉節(jié)點(diǎn)就是最終的數(shù)據(jù)節(jié)點(diǎn)，而非聚集索引的葉節(jié)仍然是索引節(jié)點(diǎn)，但它有一個(gè)指向最終數(shù)據(jù)的指針。

常見(jiàn)的數(shù)據(jù)庫(kù)索引實(shí)現(xiàn)有

平衡樹(shù)（B樹(shù)）

B+樹(shù)

Hashes（哈希）

參考B-tree wiki，B+ tree wiki

MySQL數(shù)據(jù)庫(kù)支持多種索引類(lèi)型，如B+ Tree索引，哈希索引，全文索引等等。下面只分析B+ Tree索引。

MyISAM引擎使用B+Tree作為索引實(shí)現(xiàn)，并且所有的索引都是非聚集索引。
下圖是主鍵索引：

若在Col2上建立輔助索引，其依然是一個(gè)非聚集索引，與主鍵索引類(lèi)似：

MyISAM引擎中，使用索引查找數(shù)據(jù)時(shí)，先通過(guò)索引獲取到數(shù)據(jù)的物理地址，然后通過(guò)物理地址讀取數(shù)據(jù)。

InnoDB引擎同樣使用B+Tree作為索引實(shí)現(xiàn)，但與MyISAM不同，在InnoDB引擎中，主鍵索引是聚集索引，而輔助索引則是非聚集索引。下圖是主鍵索引：

若在Col2上建立輔助索引，則是一個(gè)非聚集索引，葉節(jié)點(diǎn)的值為數(shù)據(jù)的主鍵：

在InnoDB中，通過(guò)主鍵索引，可以直接獲取到具體的數(shù)據(jù)；而通過(guò)輔助索引，在葉節(jié)點(diǎn)獲取到的是數(shù)據(jù)的主鍵，然后再通過(guò)主鍵索引最終獲取到數(shù)據(jù)。

在上面的介紹中，我們主要是針對(duì)一個(gè)字段建立索引，而實(shí)際上，可以建立一個(gè)基于多個(gè)字段的索引。假設(shè)某張表中有a，b，c，d四個(gè)字段?，F(xiàn)在在a，b，c上建立索引(a,b,c)（注意: a,b,c順序不同建立的是不同的索引）。則索引首先會(huì)按a字段排序；在a字段相同的情況下按照b字段排序；在a，b字段相同的情況下按照c字段排序，以此類(lèi)推。。。

當(dāng)建立聯(lián)合索引時(shí)，該索引的所有最左前綴匹配可以用于優(yōu)化查找。以上面建立的(a,b,c)索引為例，其所有最左前綴匹配為(a),(a,b),(a,b,c)。即涉及到(a),(a,b),(a,b,c)的查找都可以利用索引(a,b,c)，但涉及(a,c)的查找無(wú)法利用索引(a,b,c)，因?yàn)?a,c)不滿足最左前綴匹配原則。

前綴索引就是針對(duì)字段的“前特定個(gè)字符”建立索引，而非對(duì)整個(gè)字段的值建立索引。顯然，因?yàn)闆](méi)有對(duì)完整的字段值建立索引，所以這樣建立的索引更小，查詢更快。MySQL的前綴索引能有效減小索引文件的大小，提高索引的速度。但是前綴索引也有它的壞處：MySQL 不能在 ORDER BY 或 GROUP BY 中使用前綴索引，也不能把它們用作覆蓋索引(Covering Index)。
可以通過(guò)下面的預(yù)發(fā)建立前綴索引：

ALTER TABLE table_name ADD KEY(column_name(prefix_length));

覆蓋索引（covering index）指一個(gè)查詢語(yǔ)句的執(zhí)行只需要從輔助索引中就可以得到查詢記錄，而不需要查詢聚集索引中的記錄。也可以稱之為實(shí)現(xiàn)了索引覆蓋。輔助索引不包含一整行的記錄，因此可以大大減少I(mǎi)O操作。覆蓋索引是mysql dba常用的一種SQL優(yōu)化手段。

如果查詢中的列不是獨(dú)立的，則MySQL就不會(huì)使用索引。“獨(dú)立的列”是指索引列不能是表達(dá)式的一部分，也不能是函數(shù)的參數(shù)。因此應(yīng)該簡(jiǎn)化WHERE條件，始終將索引列多帶帶放在比較符號(hào)的一側(cè)

SELECT actor_id FROM sakila.actor WHERE actor_id + 1 = 5;(無(wú)法使用actor_id列的索引)
SELECT actor_id FROM sakila.actor WHERE actor_id = 4;(可以使用actor_id列的索引)

有時(shí)候需要索引很長(zhǎng)的字符列，這會(huì)使索引變得大且慢。通常可以索引開(kāi)始的部分字符，這樣可以大大節(jié)約索引空間，從而提高索引效率。但這樣也會(huì)降低索引的選擇性。索引的選擇性是指，不重復(fù)的索引值（也稱為基數(shù)）和數(shù)據(jù)的記錄總數(shù)（#T）的比值，范圍從1/#T到1之間。索引的選擇性越高則查詢效率越高。唯一索引的選擇性是1，這是最好的索引選擇性，性能也是最好的。

一般情況下某個(gè)列的前綴的選擇性也是足夠高的，足以滿足查詢性能。對(duì)于BLOB，TEXT或很長(zhǎng)的VARCHAR類(lèi)型的列，必須使用前綴索引，因?yàn)镸ySQL不允許索引這些列的完整長(zhǎng)度。通常情況，我們應(yīng)該盡量使前綴的“基數(shù)”接近于完整列的“基數(shù)”。

前綴索引的缺點(diǎn) : MySQL無(wú)法使用前綴索引做ORDER BY和GROUP BY，也無(wú)法使用前綴索引做覆蓋掃描。

在多個(gè)列上建立獨(dú)立的單列索引大部分情況下并不能提高M(jìn)ySQL的查詢性能。此時(shí)應(yīng)該考慮建立多列索引。

當(dāng)不需要考慮排序和分組時(shí)，通常將選擇性最高的列放到索引最前列。
有時(shí)可能需要根據(jù)那些運(yùn)行頻率最高的查詢來(lái)調(diào)整索引列的順序。

如果一個(gè)索引包含（或者說(shuō)是覆蓋）所有需要查詢的字段的值，我們就稱為“覆蓋索引”，使用覆蓋索引能夠極大地提高性能。

MySQL可以使用同一個(gè)索引既滿足排序，又用于查找行。因此，如果可能，涉及索引時(shí)應(yīng)該盡可能地同時(shí)滿足這兩種任務(wù)。只有當(dāng)索引的列順序和ORDER BY子句的順序完全一致，并且索引列的排序方向（倒序或正序）都一樣時(shí)，MySQL才能使用索引來(lái)對(duì)結(jié)果排序。如果查詢需要關(guān)聯(lián)多張表，則只有當(dāng)ORDER BY子句引用的字段全部為第一個(gè)表時(shí)，才能使用索引做排序。ORDER BY子句和查找型查詢的限制是一樣的：需要滿足索引的最左前綴需求；否則，MySQL都需要執(zhí)行排序操作，而無(wú)法利用索引排序。

重復(fù)索引是指在相同的列上按照相同的順序創(chuàng)建相同類(lèi)型的索引，應(yīng)該避免這樣創(chuàng)建的重復(fù)索引，發(fā)現(xiàn)后也應(yīng)該立即移除。MySQL允許在相同列上創(chuàng)建多個(gè)索引。MySQL需要多帶帶維護(hù)重復(fù)的索引，并且優(yōu)化器在優(yōu)化查詢的時(shí)候也需要逐個(gè)地進(jìn)行考慮，這會(huì)影響性能。

冗余索引和重復(fù)索引又一些不同。如果創(chuàng)建了索引（A,B）,再創(chuàng)建索引（A）就是冗余索引，因?yàn)檫@只是前一個(gè)索引的前綴索引。大多數(shù)情況下，都不需要冗余索引，應(yīng)該盡可能擴(kuò)展已有的索引而不是創(chuàng)建新索引。但也有時(shí)候出于性能方面的考慮需要冗余索引，因?yàn)閿U(kuò)展已有的索引會(huì)導(dǎo)致其變得太大，從而影響其他使用該索引的查詢的性能。

若一個(gè)索引不再被使用，則應(yīng)該考慮刪除?？梢酝ㄟ^(guò)一些工具找到未使用的索引，如Percona Toolkit中的pt-index-usage