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

數(shù)據(jù)庫索引是一種數(shù)據(jù)結(jié)構(gòu)。通過增加額外的寫操作和存儲空間來維護數(shù)據(jù)庫索引，可以提高從數(shù)據(jù)庫中讀取數(shù)據(jù)的速度。通過索引，不需要搜索數(shù)據(jù)庫的每一條記錄，就可以快速地定位到特定的數(shù)據(jù)。索引可以建在在表中某一個字段或多個字段之上?？偠灾簲?shù)據(jù)庫索引是一種數(shù)據(jù)結(jié)構(gòu)

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

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

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

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

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

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

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

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

平衡樹（B樹）

B+樹

Hashes（哈希）

參考B-tree wiki，B+ tree wiki

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

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

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

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

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

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

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

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

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

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

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

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

如果查詢中的列不是獨立的，則MySQL就不會使用索引?！蔼毩⒌牧小笔侵杆饕胁荒苁潜磉_式的一部分，也不能是函數(shù)的參數(shù)。因此應(yīng)該簡化WHERE條件，始終將索引列多帶帶放在比較符號的一側(cè)

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

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

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

前綴索引的缺點 : MySQL無法使用前綴索引做ORDER BY和GROUP BY，也無法使用前綴索引做覆蓋掃描。

在多個列上建立獨立的單列索引大部分情況下并不能提高MySQL的查詢性能。此時應(yīng)該考慮建立多列索引。

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

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

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

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

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

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