mysql索引之一：索引基礎（B-Tree索引、哈希索引、聚簇索引、全文(Full-text)索引區別）（惟一索引、最左前綴索引、前綴索引、多列索引）

沒有索引時mysql是如何查詢到數據的

　　索引對查詢的速度有着相當重要的影響，理解索引也是進行數據庫性能調優的起點。考慮以下狀況，假設數據庫中一個表有10^6條記錄，DBMS的頁面大小爲4K，並存儲100條記錄。若是沒有索引，查詢將對整個表進行掃描，最壞的狀況下，若是全部數據頁都不在內存，須要讀取10^4個頁面，若是這10^4個頁面在磁盤上隨機分佈，須要進行10^4次I/O，假設磁盤每次I/O時間爲10ms(忽略數據傳輸時間)，則總共須要100s(但實際上要好不少不少)。若是對之創建B-Tree索引，則只須要進行log100(10^6)=3次頁面讀取，最壞狀況下耗時30ms。這就是索引帶來的效果，不少時候，當你的應用程序進行SQL查詢速度很慢時，應該想一想是否能夠建索引。

進入正題：

1、什麼是索引？ 　　

　　索引（在MYSQL中也叫作鍵<key>），是存儲引擎用於快速找到記錄的一種數據結構。索引用來快速地尋找那些具備特定值的記錄，全部MySQL索引都以B-樹的形式保存。若是沒有索引，執行查詢時MySQL必須從第一個記錄開始掃描整個表的全部記錄，直至找到符合要求的記錄。表裏面的記錄數量越多，這個操做的代價就越高。若是做爲搜索條件的列上已經建立了索引，MySQL無需掃描任何記錄便可迅速獲得目標記錄所在的位置。若是表有1000個記錄，經過索引查找記錄至少要比順序掃描記錄快100倍。 

　　索引對查詢的速度有着相當重要的影響，理解索引也是進行數據庫性能調優的起點。考慮以下狀況，假設數據庫中一個表有10^6條記錄，DBMS的頁面大小爲4K，並存儲100條記錄。若是沒有索引，查詢將對整個表進行掃描，最壞的狀況下，若是全部數據頁都不在內存，須要讀取10^4個頁面，若是這10^4個頁面在磁盤上隨機分佈，須要進行10^4次I/O，假設磁盤每次I/O時間爲10ms(忽略數據傳輸時間)，則總共須要100s(但實際上要好不少不少)。若是對之創建B-Tree索引，則只須要進行log100(10^6)=3次頁面讀取，最壞狀況下耗時30ms。這就是索引帶來的效果，不少時候，當你的應用程序進行SQL查詢速度很慢時，應該想一想是否能夠建索引。

索引優化應該是對查詢性能優化最有效的手段了，索引可以輕易將查詢性能提升幾個數量級，」最優「的索引有時比一個」好的「索引性能要好兩個數量級。建立一個真正」最優「的索引常常要重寫查詢。

2、索引的類型

 

從數據結構角度

一、B+樹索引(O(log(n)))：關於B+樹索引，能夠參考 MySQL索引背後的數據結構及算法原理

二、hash索引：
a 僅僅能知足"=","IN"和"<=>"查詢，不能使用範圍查詢
b 其檢索效率很是高，索引的檢索能夠一次定位，不像B-Tree 索引須要從根節點到枝節點，最後才能訪問到頁節點這樣屢次的IO訪問，因此 Hash 索引的查詢效率要遠高於 B-Tree 索引
c 只有Memory存儲引擎顯示支持hash索引

三、FULLTEXT索引（如今MyISAM和InnoDB引擎都支持了）

四、R-Tree索引（用於對GIS數據類型建立SPATIAL索引）

從物理存儲角度

一、彙集索引（clustered index）

二、非彙集索引（non-clustered index）

從邏輯角度

一、主鍵索引：主鍵索引是一種特殊的惟一索引，不容許有空值

二、普通索引或者單列索引

三、多列索引（複合索引）：複合索引指多個字段上建立的索引，只有在查詢條件中使用了建立索引時的第一個字段，索引纔會被使用。使用複合索引時遵循最左前綴集合

四、惟一索引或者非惟一索引

五、空間索引：空間索引是對空間數據類型的字段創建的索引，MYSQL中的空間數據類型有4種，分別是GEOMETRY、POINT、LINESTRING、POLYGON。MYSQL使用SPATIAL關鍵字進行擴展，使得可以用於建立正規索引類型的語法建立空間索引。建立空間索引的列，必須將其聲明爲NOT NULL，空間索引只能在存儲引擎爲MYISAM的表中建立

 

3、索引的類型的詳解

3.1MySQL提供多種索引類型（按照邏輯角度分）供選擇： 

3.1.1普通索引
這是最基本的索引類型，並且它沒有惟一性之類的限制。普通索引能夠經過如下幾種方式建立： 
建立索引，例如CREATE INDEX <索引的名字> ON tablename (列的列表); 
修改表，例如ALTER TABLE tablename ADD INDEX [索引的名字] (列的列表); 
建立表的時候指定索引，例如CREATE TABLE tablename ( [...], INDEX [索引的名字] (列的列表) ); 

3.1.2惟一性索引 
這種索引和前面的「普通索引」基本相同，但有一個區別：索引列的全部值都只能出現一次，即必須惟一。惟一性索引能夠用如下幾種方式建立： 
建立索引，例如CREATE UNIQUE INDEX <索引的名字> ON tablename (列的列表); 
修改表，例如ALTER TABLE tablename ADD UNIQUE [索引的名字] (列的列表); 
建立表的時候指定索引，例如CREATE TABLE tablename ( [...], UNIQUE [索引的名字] (列的列表) ); 

3.1.3主鍵
主鍵是一種惟一性索引，但它必須指定爲「PRIMARY KEY」。若是你曾經用過AUTO_INCREMENT類型的列，你可能已經熟悉主鍵之類的概念了。主鍵通常在建立表的時候指定，例如「CREATE TABLE tablename ( [...], PRIMARY KEY (列的列表) ); 」。可是，咱們也能夠經過修改表的方式加入主鍵，例如「ALTER TABLE tablename ADD PRIMARY KEY (列的列表); 」。每一個表只能有一個主鍵。 

3.1.4全文索引 
MySQL從3.23.23版開始支持全文索引和全文檢索。在MySQL中，全文索引的索引類型爲FULLTEXT。全文索引能夠在VARCHAR或者 TEXT類型的列上建立。它能夠經過CREATE TABLE命令建立，也能夠經過ALTER TABLE或CREATE INDEX命令建立。對於大規模的數據集，經過ALTER TABLE（或者CREATE INDEX）命令建立全文索引要比把記錄插入帶有全文索引的空表更快。本文下面的討論再也不涉及全文索引，要了解更多信息，請參見MySQL documentation。 詳細見：mysql全文索引

3.1.5單列索引與多列索引 
索引能夠是單列索引，也能夠是多列索引。下面咱們經過具體的例子來講明這兩種索引的區別。

示例：假設有這樣一個people表： 

CREATE TABLE people ( peopleid SMALLINT NOT NULL AUTO_INCREMENT, firstname CHAR(50) NOT NULL, lastname CHAR(50) NOT NULL, age SMALLINT NOT NULL, townid SMALLINT NOT NULL, PRIMARY KEY (peopleid) ); 

下面是咱們插入到這個people表的數據： 
這個數據片斷中有四個名字爲「Mikes」的人（其中兩個姓Sullivans，兩個姓McConnells），有兩個年齡爲17歲的人，還有一個名字不同凡響的Joe Smith。 

這個表的主要用途是根據指定的用戶姓、名以及年齡返回相應的peopleid。例如，咱們可能須要查找姓名爲Mike Sullivan、年齡17歲用戶的peopleid（SQL命令爲SELECT peopleid FROM people WHERE firstname='Mike' AND lastname='Sullivan' AND age=17;）。因爲咱們不想讓MySQL每次執行查詢就去掃描整個表，這裏須要考慮運用索引。 

首先，咱們能夠考慮在單個列上建立索引，好比firstname、lastname或者age列。若是咱們建立firstname列的索引（ALTER TABLE people ADD INDEX firstname (firstname);），MySQL將經過這個索引迅速把搜索範圍限制到那些firstname='Mike'的記錄，而後再在這個「中間結果集」上 進行其餘條件的搜索：它首先排除那些lastname不等於「Sullivan」的記錄，而後排除那些age不等於17的記錄。當記錄知足全部搜索條件之 後，MySQL就返回最終的搜索結果。 

因爲創建了firstname列的索引，與執行表的徹底掃描相比，MySQL的效率提升了不少，但咱們要求MySQL掃描的記錄數量仍舊遠遠超過了實際所 須要的。雖然咱們能夠刪除firstname列上的索引，再建立lastname或者age列的索引，但總地看來，不論在哪一個列上建立索引搜索效率仍舊相 似。 

爲了提升搜索效率，咱們須要考慮運用多列索引。若是爲firstname、lastname和age這三個列建立一個多列索引，一個多列索引能夠由最多15個列組成。MySQL只需一次檢索就可以找出正確的結果！下面是建立這個多列索引的SQL命令： 

ALTER TABLE people ADD INDEX fname_lname_age (firstname,lastname,age); 

因爲索引文件以B-樹格式保存，MySQL可以當即轉到合適的firstname，而後再轉到合適的lastname，最後轉到合適的age。在沒有掃描數據文件任何一個記錄的狀況下，MySQL就正確地找出了搜索的目標記錄！ 

那麼，若是在firstname、lastname、age這三個列上分別建立單列索引，效果是否和建立一個firstname、lastname、 age的多列索引同樣呢？答案是否認的，二者徹底不一樣。當咱們執行查詢的時候，MySQL只能使用一個索引。若是你有三個單列的索引，MySQL會試圖選擇一個限制最嚴格的索引。可是，即便是限制最嚴格的單列索引，它的限制能力也確定遠遠低於firstname、lastname、age這三個列上的多列索引。 

3.1.6最左前綴 
多列索引還有另一個優勢，它經過稱爲最左前綴（Leftmost Prefixing）的概念體現出來。繼續考慮前面的例子，如今咱們有一個firstname、lastname、age列上的多列索引，咱們稱這個索引 爲fname_lname_age。當搜索條件是如下各類列的組合時，MySQL將使用fname_lname_age索引： 
firstname，lastname，age 
firstname，lastname 
firstname 
從另外一方面理解，它至關於咱們建立了(firstname，lastname，age)、(firstname，lastname)以及(firstname)這些列組合上的索引。下面這些查詢都可以使用這個fname_lname_age索引： 

SELECT peopleid FROM people WHERE firstname='Mike' AND lastname='Sullivan' AND age='17'; 
SELECT peopleid FROM people WHERE firstname='Mike' AND lastname='Sullivan'; 
SELECT peopleid FROM people WHERE firstname='Mike'; 

#The following queries cannot use the index at all: 
SELECT peopleid FROM people WHERE lastname='Sullivan'; 
SELECT peopleid FROM people WHERE age='17'; 
SELECT peopleid FROM people WHERE lastname='Sullivan' AND age='17'; 

3.1.7空間索引

使用SPATIAL參數能夠設置索引爲空間索引。空間索引只能創建在空間數據類型上，這樣能夠提升系統獲取空間數據的效率。MySQL中的空間數據類型包括GEOMETRY和POINT、LINESTRING和POLYGON等。目前只有MyISAM存儲引擎支持空間檢索，並且索引的字段不能爲空值。對於初學者來講，這類索引不多會用到。

 

3.二、索引的類型（從數據結構角度）

索引是在存儲引擎中實現的，而不是在服務器層中實現的。因此，每種存儲引擎的索引都不必定徹底相同，並非全部的存儲引擎都支持全部的索引類型。

3.2.一、B-Tree索引

B－Tree：每個葉子節點都包含指向下一個葉子節點的指針，從而方便葉子節點的範圍遍歷。B－Tree一般意味着全部的值都是按順序存儲的，而且每個葉子頁到根的距離相同，很適合查找範圍數據。

B+樹是一個平衡的多叉樹，從根節點到每一個葉子節點的高度差值不超過1，並且同層級的節點間有指針相互連接。

在B+樹上的常規檢索，從根節點到葉子節點的搜索效率基本至關，不會出現大幅波動，並且基於索引的順序掃描時，也能夠利用雙向指針快速左右移動，效率很是高。

所以，B+樹索引被普遍應用於數據庫、文件系統等場景。順便說一下，xfs文件系統比ext3/ext4效率高不少的緣由之一就是，它的文件及目錄索引結構所有采用B+樹索引，而ext3/ext4的文件目錄結構則採用Linked list, hashed B-tree、Extents/Bitmap等索引數據結構，所以在高I/O壓力下，其IOPS能力不如xfs。

假設有以下一個表：

CREATE TABLE People (
   last_name varchar(50)    not null,
   first_name varchar(50)    not null,
   dob        date           not null,
   gender     enum('m', 'f') not null,
   key(last_name, first_name, dob)
);

其索引包含表中每一行的last_name、first_name和dob列。其結構大體以下：

  

 索引存儲的值按索引列中的順序排列。能夠利用B-Tree索引進行全關鍵字、關鍵字範圍和關鍵字前綴查詢，固然，若是想使用索引，你必須保證按索引的最左邊前綴(leftmost prefix of the index)來進行查詢。
(1)匹配全值(Match the full value)：對索引中的全部列都指定具體的值。例如，上圖中索引能夠幫助你查找出生於1960-01-01的Cuba Allen。
(2)匹配最左前綴(Match a leftmost prefix)：你能夠利用索引查找last name爲Allen的人，僅僅使用索引中的第1列。
(3)匹配列前綴(Match a column prefix)：例如，你能夠利用索引查找last name以J開始的人，這僅僅使用索引中的第1列。
(4)匹配值的範圍查詢(Match a range of values)：能夠利用索引查找last name在Allen和Barrymore之間的人，僅僅使用索引中第1列。
(5)匹配部分精確而其它部分進行範圍匹配(Match one part exactly and match a range on another part)：能夠利用索引查找last name爲Allen，而first name以字母K開始的人。
(6)僅對索引進行查詢(Index-only queries)：若是查詢的列都位於索引中，則不須要讀取元組的值。(覆蓋索引)
因爲B-樹中的節點都是順序存儲的，因此能夠利用索引進行查找(找某些值)，也能夠對查詢結果進行ORDER BY。

固然，使用B-tree索引有如下一些限制：
(1) 查詢必須從索引的最左邊的列開始，不然沒法使用索引。關於這點已經提了不少遍了。例如你不能利用索引查找在某一天出生的人。
(2) 不能跳過某一索引列。例如，你不能利用索引查找last name爲Smith且出生於某一天的人。
(3) 存儲引擎不能使用索引中範圍條件右邊的列。例如，若是你的查詢語句爲WHERE last_name="Smith" AND first_name LIKE 'J%' AND dob='1976-12-23'，則該查詢只會使用索引中的前兩列，由於LIKE是範圍查詢。

3.2.二、Hash索引

哈希索引基於哈希表實現，只有精確索引全部列的查詢纔有效。對於每一行數據，存儲引擎都會對全部的索引列計算一個哈希碼，哈希碼是一個較小的值，而且不一樣鍵值的行計算出來的哈希碼也不同。哈希索引將全部的哈希存儲在索引中，同時在哈希表中保存指向每一個數據的指針。

MySQL中，只有Memory存儲引擎顯示支持hash索引，是Memory表的默認索引類型，儘管Memory表也可使用B-Tree索引。Memory存儲引擎支持非惟一hash索引，這在數據庫領域是罕見的，若是多個值有相同的hash code，索引把它們的行指針用鏈表保存到同一個hash表項中。
假設建立以下一個表：

CREATE TABLE testhash (
   fname VARCHAR(50) NOT NULL,
   lname VARCHAR(50) NOT NULL,
   KEY USING HASH(fname)
) ENGINE=MEMORY;

包含的數據以下：

假設索引使用hash函數f( )，以下：

f('Arjen') = 2323
f('Baron') = 7437
f('Peter') = 8784
f('Vadim') = 2458

 

此時，索引的結構大概以下：

哈希索引中存儲的是：哈希值+數據行指針 

Slots是有序的，可是記錄不是有序的。當你執行
mysql> SELECT lname FROM testhash WHERE fname='Peter';
MySQL會計算’Peter’的hash值，而後經過它來查詢索引的行指針。由於f('Peter') = 8784，MySQL會在索引中查找8784，獲得指向記錄3的指針。
由於索引本身僅僅存儲很短的值，因此，索引很是緊湊。Hash值不取決於列的數據類型，一個TINYINT列的索引與一個長字符串列的索引同樣大。
 
Hash索引有如下一些限制：
(1)因爲索引僅包含hash code和記錄指針，因此，MySQL不能經過使用索引避免讀取記錄。可是訪問內存中的記錄是很是迅速的，不會對性形成太大的影響。
(2)哈希索引數據並非按照索引值順序存儲的，因此不能使用hash索引排序。
(3)Hash索引不支持鍵的部分匹配，由於是經過整個索引值來計算hash值的。例如，在數據列（A,B）上創建哈希索引，若是查詢只有數據列A，則沒法使用該索引。
(4)Hash索引只支持等值比較，例如使用=，IN( )和<=>。對於WHERE price>100並不能加速查詢。
(5)訪問Hash索引的速度很是快，除非有不少哈希衝突（不一樣的索引列值卻有相同的哈希值）。當出現哈希衝突的時候，存儲引擎必須遍歷鏈表中全部的行指針，逐行進行比較，直到找到全部符合條件的行。
(6)若是哈希衝突不少的話，一些索引維護操做的代價也會很高。當從表中刪除一行時，存儲引擎要遍歷對應哈希值的鏈表中的每一行，找到並刪除對應行的引用，衝突越多，代價越大。

 

InnoDB引擎有一個特殊的功能叫作「自適應哈希索引」。當InnoDB注意到某些索引值被使用得很是頻繁時，它會在內存中基於B-Tree索引上再建立一個哈希索引，這樣就像B-Tree索引也具備哈希索引的一些優勢，好比快速的哈希查找。

建立哈希索引：若是存儲引擎不支持哈希索引，則能夠模擬像InnoDB同樣建立哈希索引，這能夠享受一些哈希索引的便利，例如只須要很小的索引就能夠爲超長的鍵建立索引。

思路很簡單：在B-Tree基礎上建立一個僞哈希索引。這和真正的哈希索引不是一回事，由於仍是使用B-Tree進行查找，可是它使用哈希值而不是鍵自己進行索引查找。你須要作的就是在查詢的where子句中手動指定使用哈希函數。這樣實現的缺陷是須要維護哈希值。能夠手動維護，也可使用觸發器實現。

若是採用這種方式，記住不要使用SHA1和MD5做爲哈希函數。由於這兩個函數計算出來的哈希值是很是長的字符串，會浪費大量空間，比較時也會更慢。SHA1和MD5是強加密函數，設計目標是最大限度消除衝突，但這裏並不須要這樣高的要求。簡單哈希函數的衝突在一個能夠接受的範圍，同時又可以提供更好的性能。

若是數據表很是大，CRC32會出現大量的哈希衝突，CRC32返回的是32位的整數，當索引有93000條記錄時出現衝突的機率是1%。

處理哈希衝突：當使用哈希索引進行查詢時，必須在where子句中包含常量值。

3.2.三、空間(R-Tree)索引

MyISAM支持空間索引，主要用於地理空間數據類型，例如GEOMETRY。和B-TREE索引不一樣，這類索引無須前綴查詢。空間索引會從全部到維度來索引數據。查詢時，能夠有效地使用任意維度來組合查詢。必須使用MySQL的GIS相關函數如MBRCONTAINS()等來維護數據。MySQL的GIS支持並不完善，因此大部分人都不會使用這個特性。開源關係數據庫系統中對GIS的解決方案作得比較好的是PostgreSQL的PostGIS。

3.2.四、全文(Full-text)索引
全文索引是MyISAM的一個特殊索引類型，innodb的5.6以上版本也支持，它查找的是文本中的關鍵詞主要用於全文檢索。

全文索引是一種特殊類型的索引，它查找都是文本中的關鍵詞，而不是直接比較索引中的值。全文搜索和其餘幾類索引匹配方式徹底不同。它有許多須要注意的細節，如停用詞、詞幹和複數、布爾搜索等。全文索引更相似於搜索引擎作的事情，而不是簡單的WHERE條件匹配。

在相同的列上同時建立全文索引和基於值對B-Tree索引不會有衝突，全文索引適用於MATCH AGAINST操做，而不是普通的WHERE條件操做。

3.三、從物理存儲角度索引分類

3.3.一、聚簇索引(Clustered Indexes)

聚簇索引保證關鍵字的值相近的元組存儲的物理位置也相同（因此字符串類型不宜創建聚簇索引，特別是隨機字符串，會使得系統進行大量的移動操做），且一個表只能有一個聚簇索引。由於由存儲引擎實現索引，因此，並非全部的引擎都支持聚簇索引。目前，只有solidDB和InnoDB支持。

3.3.二、非聚簇索引

3.3.三、聚簇索引的結構大體以下：

葉子頁包含了行的所有數據，可是節點頁只包含了索引列。

二級索引葉子節點保存的不是指行的物理位置的指針，而是行的主鍵值。這意味着經過二級索引查找行，存儲引擎須要找到二級索引的葉子節點獲取對應的主鍵值，而後根據這個值去聚簇索引中查找到對應的行。這裏作了重複的工做：兩次B－TREE查找而不是一次。

 

 注：葉子頁面包含完整的元組，而內節點頁面僅包含索引的列(索引的列爲整型)。一些DBMS容許用戶指定聚簇索引，可是MySQL的存儲引擎到目前爲止都不支持。InnoDB對主鍵創建聚簇索引。若是你不指定主鍵，InnoDB會用一個具備惟一且非空值的索引來代替。若是不存在這樣的索引，InnoDB會定義一個隱藏的主鍵，而後對其創建聚簇索引。通常來講，DBMS都會以聚簇索引的形式來存儲實際的數據，它是其它二級索引的基礎。

3.3.四、InnoDB和MyISAM的數據佈局的比較
爲了更加理解聚簇索引和非聚簇索引，或者primary索引和second索引(MyISAM不支持聚簇索引)，來比較一下InnoDB和MyISAM的數據佈局，對於以下表：

CREATE TABLE layout_test (
   col1 int NOT NULL,
   col2 int NOT NULL,
   PRIMARY KEY(col1),
   KEY(col2)
);

假設主鍵的值位於1---10,000之間，且按隨機順序插入，而後用OPTIMIZE TABLE進行優化。col2隨機賦予1---100之間的值，因此會存在許多重複的值。

(1)    MyISAM的數據佈局
其佈局十分簡單，MyISAM按照插入的順序在磁盤上存儲數據，以下：

 注：左邊爲行號(row number)，從0開始。由於元組的大小固定，因此MyISAM能夠很容易的從表的開始位置找到某一字節的位置。
MyISAM創建的primary key的索引結構大體以下：

 注：MyISAM不支持聚簇索引，索引中每個葉子節點僅僅包含行號(row number)，且葉子節點按照col1的順序存儲。
來看看col2的索引結構：

 實際上，在MyISAM中，primary key和其它索引沒有什麼區別。Primary key僅僅只是一個叫作PRIMARY的惟一，非空的索引而已，葉子節點按照col2的順序存儲。

(2)    InnoDB的數據佈局
InnoDB按聚簇索引的形式存儲數據，因此它的數據佈局有着很大的不一樣。它存儲表的結構大體以下：

 注：聚簇索引中的每一個葉子節點包含primary key的值，事務ID和回滾指針(rollback pointer)——用於事務和MVCC，和餘下的列(如col2)。

相對於MyISAM，InnoDB的二級索引與聚簇索引有很大的不一樣。InnoDB的二級索引的葉子包含primary key的值，而不是行指針(row pointers)，這樣的策略減少了移動數據或者數據頁面分裂時維護二級索引的開銷，由於InnoDB不須要更新索引的行指針。其結構大體以下：

 聚簇索引和非聚簇索引表的對比：

 

 

3.3.四、按primary key的順序插入行(InnoDB)

若是你用InnoDB，並且不須要特殊的聚簇索引，一個好的作法就是使用代理主鍵(surrogate key)——獨立於你的應用中的數據。最簡單的作法就是使用一個AUTO_INCREMENT的列，這會保證記錄按照順序插入，並且能提升使用primary key進行鏈接的查詢的性能。應該儘可能避免隨機的聚簇主鍵，例如，字符串主鍵就是一個很差的選擇，它使得插入操做變得隨機。

 

4、覆蓋索引(Covering Indexes)

mysql索引之六：mysql高效索引之覆蓋索引

　　覆蓋索引是一種很是強大的工具，能大大提升查詢性能。設計優秀的索引應該考慮到整個查詢，而不僅僅的where條件部分。索引確實是一種查找數據的高效方式，可是MYSQL也可使用索引來直接獲取列的數據，這樣就再也不須要讀取數據行。索引的葉子節點中已經包含要查詢的數據，那麼就沒有必要再回表查詢了，若是索引包含知足查詢的全部數據，就稱爲覆蓋索引。

　　解釋一： 就是select的數據列只用從索引中就可以取得，沒必要從數據表中讀取，換句話說查詢列要被所使用的索引覆蓋。
　　解釋二： 索引是高效找到行的一個方法，當能經過檢索索引就能夠讀取想要的數據，那就不須要再到數據表中讀取行了。若是一個索引包含了（或覆蓋了）知足查詢語句中字段與條件的數據就叫作覆蓋索引。
　　解釋三： 是非彙集組合索引的一種形式，它包括在查詢裏的Select、Join和Where子句用到的全部列（即創建索引的字段正好是覆蓋查詢語句[select子句]與查詢條件[Where子句]中所涉及的字段，也即，索引包含了查詢正在查找的全部數據）。

只須要讀取索引而不用讀取數據有如下一些優勢：
(1)索引項一般比記錄要小，因此MySQL訪問更少的數據；
(2)索引都按值的大小順序存儲，相對於隨機訪問記錄，須要更少的I/O；
(3)大多數據引擎能更好的緩存索引。好比MyISAM只緩存索引。
(4)覆蓋索引對於InnoDB表尤爲有用，由於InnoDB使用匯集索引組織數據，若是二級索引中包含查詢所需的數據，就再也不須要在彙集索引中查找了。
覆蓋索引不能是任何索引，只有B-TREE索引存儲相應的值。並且不一樣的存儲引擎實現覆蓋索引的方式都不一樣，並非全部存儲引擎都支持覆蓋索引(Memory和Falcon就不支持)。
對於索引覆蓋查詢(index-covered query)，使用EXPLAIN時，能夠在Extra一列中看到「Using index」。例如，在sakila的inventory表中，有一個組合索引(store_id,film_id)，對於只須要訪問這兩列的查詢，MySQL就可使用索引，以下：

mysql> EXPLAIN SELECT store_id, film_id FROM sakila.inventory\G

*************************** 1. row ***************************
           id: 1
 select_type: SIMPLE
        table: inventory
         type: index
possible_keys: NULL
          key: idx_store_id_film_id
      key_len: 3
          ref: NULL
         rows: 5007
        Extra: Using index
1 row in set (0.17 sec)

（同時查詢actor_id[主鍵]與last_name[索引字段]）在大多數引擎中，只有當查詢語句所訪問的列是索引的一部分時，索引纔會覆蓋。可是，InnoDB不限於此，InnoDB的二級索引在葉子節點中存儲了primary key的值。所以，sakila.actor表使用InnoDB，並且對因而last_name上有索引，因此，索引能覆蓋那些訪問actor_id的查詢，如：

mysql> EXPLAIN SELECT actor_id, last_name
    -> FROM sakila.actor WHERE last_name = 'HOPPER'\G
*************************** 1. row ***************************
           id: 1
 select_type: SIMPLE
        table: actor
         type: ref
possible_keys: idx_actor_last_name
          key: idx_actor_last_name
      key_len: 137
          ref: const
         rows: 2
        Extra: Using where; Using index

5、利用索引進行排序

MySQL中，有兩種方式生成有序結果集：

• 一是使用filesort
• 二是按索引順序掃描

若是explain出來的type列的值爲「index」，則說明MYSQL使用了索引掃描來作排序。利用索引進行排序操做是很是快的，由於只須要從一條索引記錄移動到緊接着的下一條記錄。但若是索引不能覆蓋查詢所需的所有列，那就不得不每掃描一條索引記錄就回表查詢一次對應的行，這基本上都是隨機IO，所以按索引順序讀取的速度一般要比順序地全表掃描慢，尤爲是在IO密集型的工做負載時。

並且能夠利用同一索引同時進行查找和排序操做。當索引的順序與ORDER BY中的列順序相同且全部的列是同一方向(所有升序或者所有降序)時，可使用索引來排序。若是查詢是鏈接多個表，僅當ORDER BY中的全部列都是第一個表的列時纔會使用索引。其它狀況都會使用filesort文件排序。

create table actor(
actor_id int unsigned NOT NULL AUTO_INCREMENT,
name      varchar(16) NOT NULL DEFAULT '',
password        varchar(16) NOT NULL DEFAULT '',
PRIMARY KEY(actor_id),
KEY     (name)
) ENGINE=InnoDB;
insert into actor(name,password) values('cat01','1234567');
insert into actor(name,password) values('cat02','1234567');
insert into actor(name,password) values('ddddd','1234567');
insert into actor(name,password) values('aaaaa','1234567');

explain結果：

mysql> explain select actor_id from actor order by actor_id \G
*************************** 1. row ***************************
           id: 1
 select_type: SIMPLE
        table: actor
         type: index
possible_keys: NULL
          key: PRIMARY
      key_len: 4
          ref: NULL
         rows: 4
        Extra: Using index
1 row in set (0.00 sec)


mysql> explain select actor_id from actor order by password \G
*************************** 1. row ***************************
           id: 1
 select_type: SIMPLE
        table: actor
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 4
        Extra: Using filesort
1 row in set (0.00 sec)

mysql> explain select actor_id from actor order by name \G
*************************** 1. row ***************************
           id: 1
 select_type: SIMPLE
        table: actor
         type: index
possible_keys: NULL
          key: name
      key_len: 18
          ref: NULL
         rows: 4
        Extra: Using index
1 row in set (0.00 sec)

對於filesort，MySQL有兩種排序算法。 當MySQL不能使用索引進行排序時，就會利用本身的排序算法(快速排序算法)在內存(sort buffer)中對數據進行排序，若是內存裝載不下，它會將磁盤上的數據進行分塊，再對各個數據塊進行排序，而後將各個塊合併成有序的結果集（實際上就是外排序，使用臨時表）。

(1)兩次掃描算法(Two passes)
實現方式是先將須要排序的字段和能夠直接定位到相關行數據的指針信息取出，而後在設定的內存（經過參數sort_buffer_size設定）中進行排序，完成排序以後再次經過行指針信息取出所需的Columns。
注：該算法是4.1以前採用的算法，它須要兩次訪問數據，尤爲是第二次讀取操做會致使大量的隨機I/O操做。另外一方面，內存開銷較小。

(2)一次掃描算法(single pass)
該算法一次性將所需的Columns所有取出，在內存中排序後直接將結果輸出。
注：從 MySQL 4.1 版本開始使用該算法。它減小了I/O的次數，效率較高，可是內存開銷也較大。若是咱們將並不須要的Columns也取出來，就會極大地浪費排序過程所須要的內存。在 MySQL 4.1 以後的版本中，能夠經過設置 max_length_for_sort_data 參數來控制 MySQL 選擇第一種排序算法仍是第二種。當取出的全部大字段總大小大於 max_length_for_sort_data 的設置時，MySQL 就會選擇使用第一種排序算法，反之，則會選擇第二種。爲了儘量地提升排序性能，咱們天然更但願使用第二種排序算法，因此在 Query 中僅僅取出須要的 Columns 是很是有必要的。

當對鏈接操做進行排序時，若是ORDER BY僅僅引用第一個表的列，MySQL對該表進行filesort操做，而後進行鏈接處理，此時，EXPLAIN輸出「Using filesort」；不然，MySQL必須將查詢的結果集生成一個臨時表，在鏈接完成以後進行filesort操做，此時，EXPLAIN輸出「Using temporary;Using filesort」。

 

6、索引與加鎖

索引對於InnoDB很是重要，由於它可讓查詢鎖更少的元組。這點十分重要，由於MySQL 5.0中，InnoDB直到事務提交時纔會解鎖。有兩個方面的緣由：首先，即便InnoDB行級鎖的開銷很是高效，內存開銷也較小，但無論怎麼樣，仍是存在開銷。其次，對不須要的元組的加鎖，會增長鎖的開銷，下降併發性。
InnoDB僅對須要訪問的元組加鎖，而索引可以減小InnoDB訪問的元組數。可是，只有在存儲引擎層過濾掉那些不須要的數據才能達到這種目的。一旦索引不容許InnoDB那樣作（即達不到過濾的目的），MySQL服務器只能對InnoDB返回的數據進行WHERE操做，此時，已經沒法避免對那些元組加鎖了：InnoDB已經鎖住那些元組，服務器沒法解鎖了。
來看個例子：

create table actor(
actor_id int unsigned NOT NULL AUTO_INCREMENT,
name      varchar(16) NOT NULL DEFAULT '',
password        varchar(16) NOT NULL DEFAULT '',
PRIMARY KEY(actor_id),
KEY     (name)
) ENGINE=InnoDB;
insert into actor(name,password) values('cat01','1234567');
insert into actor(name,password) values('cat02','1234567');
insert into actor(name,password) values('ddddd','1234567');
insert into actor(name,password) values('aaaaa','1234567');

SET AUTOCOMMIT=0;
BEGIN;
SELECT actor_id FROM actor WHERE actor_id < 4
AND actor_id <> 1 FOR UPDATE;

mysql> EXPLAIN SELECT actor_id FROM test.actor
    -> WHERE actor_id < 4 AND actor_id <> 1 FOR UPDATE \G
*************************** 1. row ***************************
           id: 1
 select_type: SIMPLE
        table: actor
         type: index
possible_keys: PRIMARY
          key: PRIMARY
      key_len: 4
          ref: NULL
         rows: 4
        Extra: Using where; Using index
1 row in set (0.00 sec)
mysql>

 該查詢僅僅返回2---3的數據，實際已經對1---3的數據加上排它鎖了。InnoDB鎖住元組1是由於MySQL的查詢計劃僅使用索引進行範圍查詢（而沒有進行過濾操做，WHERE中第二個條件已經沒法使用索引了）：

 

代表存儲引擎從索引的起始處開始，獲取全部的行，直到actor_id<4爲假，服務器沒法告訴InnoDB去掉元組1。
爲了證實row 1已經被鎖住，咱們另外建一個鏈接，執行以下操做：

SET AUTOCOMMIT=0;
BEGIN;
SELECT actor_id FROM actor WHERE actor_id = 1 FOR UPDATE;

 該查詢會被掛起，直到第一個鏈接的事務提交釋放鎖時，纔會執行（這種行爲對於基於語句的複製(statement-based replication)是必要的）。
如上所示，當使用索引時，InnoDB會鎖住它不須要的元組。更糟糕的是，若是查詢不能使用索引，MySQL會進行全表掃描，並鎖住每個元組，無論是否真正須要。

 

 

 

7、索引的優勢：

最多見的B-Tree索引，按照順序存儲數據，因此MYSQL能夠用來作order by和group by操做。由於數據是有序的，因此B-Tree也就會將相關的列值存儲在一塊兒。最後，由於索引中存儲了實際的列值，因此某些查詢只使用索引就可以完成所有查詢。總結下來索引有以下三個優勢：

1，索引大大減少了服務器須要掃描的數據量

2，索引能夠幫助服務器避免排序和臨時表

3，索引能夠將隨機IO變成順序IO

索引三星系統：

一星：索引將相關的記錄放到一塊兒

二星：索引中的數據順序和查找中的排列順序一致

三星：索引中的列包含了查詢中須要的所有列

 

索引是最好的解決方案嗎？

索引並不老是最好的工具。總的來講只有索引幫助存儲引擎快速查找到記錄的好處大於其帶來的額外工做時，索引纔是有效的。

對於很是小的表，大部分狀況下簡單的全表掃描更高效；

對於中到大型的表，索引就很是有效。

但對於特大型的表，創建和使用索引的代價將隨之增加。這種狀況下須要一種技術能夠直接區分出查詢須要的一組數據，而不是一條記錄一條記錄地匹配。例如使用分區技術。

若是表的數量特別多，能夠創建一個元數據信息表，用來查詢須要用到的某些特性。例如執行那些須要聚合多個應用分佈在多個表的數據的查詢，則須要記錄「哪一個用戶的信息存儲在哪一個表中」的元數據，這樣在查詢時就能夠直接忽略那些不包含指定用戶信息的表。

 

8、高性能的索引策略

 

5.1獨立的列

獨立的列是指索引列不能是表達式的一部分，也不是是函數的參數。例如如下兩個查詢沒法使用索引：

1）表達式：  select actor_id from sakila.actor where actor_id+1=5;

2）函數參數：select ... where TO_DAYS(CURRENT_DATE) - TO_DAYS(date_col)<=10;

 

5.2前綴索引和索引選擇性

　　有時須要索引很長的字符列，它會使索引變大並且變慢。一個策略就是模擬哈希索引。可是有時這也不夠好，那？

一般能夠索引開始的幾個字符，而不是所有值，以節約空間並獲得好的性能。這使索引須要的空間變小，但這樣也會下降索引的選擇性。索引的選擇性是指，不重複的索引值（基數）和數據表中的記錄總數（#T）的比值，範圍從1/#T之間。索引的選擇性越高則查詢效率越高，由於選擇性高的索引可讓MYSQL在查找時過濾掉更多的行。

惟一索引的選擇性是1，這是最好的索引選擇性，性能也是最好的。

通常狀況下某個前綴的選擇性也是足夠高的，足以知足查詢性能。對於BLOB、TEXT或者很長的VARCHAR類型的列，必須使用前綴索引，由於mysql不容許索引它們的全文化。

能夠在同一個查詢中針對許多不一樣的前綴長度進行計算，選擇選擇性好的。

(用LEFT函數，left(city,4))

添加前綴索引

mysql>alter table test.test add key (city(7));

前綴索引能很好地減小索引的大小及提升速度，可是mysql不能在order by 和group by查詢中使用前綴索引，也不能把它們用來覆蓋索引。

有時後綴索引也挺有用，例如查找某個域名的全部電子郵件地址。mysql不支持反向索引，可是能夠把反向字符串保存起來，而且索引它的前綴。能夠用觸發器維護這種索引。

決竅：在於要選擇足夠長的前綴以保證較高的選擇性，同時又不能太長（以便節約空間）。前綴應該足夠長，以使得前綴索引的選擇性接近於索引整個列。換句話說，前綴的「基數」應該接近於完整列的「基數」。爲了決定前綴的合適長度，須要找到最多見的值的列表，而後和最多見的前綴列表進行比較。例如如下查詢：

select count(*) as cnt,city from sakila.city_demo group by city order by cnt desc limit 10;

select count(*) as cnt,left(city,7) as perf  from sakila.city_demo group by city order by cnt desc limit 10;

直到這個前綴的選擇性接近完整列的選擇性。

計算合適的前綴長度的另外一個方法就是計算完整列的選擇性，並使前綴的選擇性接近於完整列的選擇性，以下：

select  count(distinct city)/count(*) from sakila.city_demo;

select  count(distinct left(city,7))/count(*) from sakila.city_demo;

前綴索引是一種能使索引更小、更快的有效辦法，但另外一方面也有其缺點：MYSQL沒法使用前綴索引作order by和group by，也沒法使用前綴索引作覆蓋掃描。

5.3多列索引

一個多列索引與多個列索引MYSQL在解析執行上是不同的，若是在explain中看到有索引合併，應該好好檢查一下查詢的表和結構是否是已經最優。

 

5.4選擇合適的索引列順序

對於如何選擇索引的順序有一個經驗法則：將選擇性最高的列放在索引最前列。

當不須要考慮排序和分組時，將選擇性最高的列放在前面一般是最好的。而後，性能不僅是依賴於全部索引列的選擇性（總體基數），也和查詢條件的具體值有關，也就是和值的分佈有關。這和前面介紹的選擇前綴的長度須要考慮的地方同樣。可能須要根據那些運行頻率最高的查詢來調整索引列的順序，讓這種狀況下索引的選擇性最高。

使用經驗法則要注意不要假設平均狀況下的性能也能表明特殊狀況下的性能，特殊狀況可能會摧毀整個應用的性能（當使用前綴索引時，在某些條件值的基數比正常值高的時候）。

 5.5單列索引、多列索引以及最左前綴 原則及使用上的特色

結合實例說明以下：如今咱們想查出知足如下條件的用戶id：
mysql>SELECT ｀uid｀ FROM people WHERE lname｀='Liu'  AND ｀fname｀='Zhiqun' AND ｀age｀=26
由於咱們不想掃描整表，故考慮用索引。

單列索引：
ALTER TABLE people ADD INDEX lname (lname);
將lname列建索引，這樣就把範圍限制在lname='Liu'的結果集1上，以後掃描結果集1，產生知足fname='Zhiqun'的結果集2，再掃描結果集2，找到 age=26的結果集3，即最終結果。

由 於創建了lname列的索引，與執行表的徹底掃描相比，效率提升了不少，但咱們要求掃描的記錄數量仍舊遠遠超過了實際所需 要的。雖然咱們能夠刪除lname列上的索引，再建立fname或者age 列的索引，可是，不論在哪一個列上建立索引搜索效率仍舊類似。

2.多列索引：
ALTER TABLE people ADD INDEX lname_fname_age (lame,fname,age);
爲了提升搜索效率，咱們須要考慮運用多列索引,因爲索引文件以B－Tree格式保存，因此咱們不用掃描任何記錄，便可獲得最終結果。

注：在mysql中執行查詢時，只能使用一個索引，若是咱們在lname,fname,age上分別建索引,執行查詢時，只能使用一個索引，mysql會選擇一個最嚴格(得到結果集記錄數最少)的索引。

3.最左前綴：顧名思義，就是最左優先，上例中咱們建立了lname_fname_age多列索引,至關於建立了(lname)單列索引，(lname,fname)組合索引以及(lname,fname,age)組合索引。

注：在建立多列索引時，要根據業務需求，where子句中使用最頻繁的一列放在最左邊。

 

 

9、分析索引效率 

如今咱們已經知道了一些如何選擇索引列的知識，但還沒法判斷哪個最有效。MySQL提供了一個內建的SQL命令幫助咱們完成這個任務，這就是 EXPLAIN命令。EXPLAIN命令的通常語法是：EXPLAIN 。你能夠在MySQL文檔找到有關該命令的更多說明。下面是一個例子： 

EXPLAIN SELECT peopleid FROM people WHERE firstname='Mike' AND lastname='Sullivan' AND age='17'; 

這個命令將返回下面這種分析結果： 

下面咱們就來看看這個EXPLAIN分析結果的含義。 
見explain章節

10、索引的缺點 

到目前爲止，咱們討論的都是索引的優勢。事實上，索引也是有缺點的。 首先，索引要佔用磁盤空間。一般狀況下，這個問題不是很突出。可是，若是你建立每一種可能列組合的索引，索引文件體積的增加速度將遠遠超過數據文件。若是你有一個很大的表，索引文件的大小可能達到操做系統容許的最大文件限制。 第二，對於須要寫入數據的操做，好比DELETE、UPDATE以及INSERT操做，索引會下降它們的速度。這是由於MySQL不只要把改動數據寫入數據文件，並且它還要把這些改動寫入索引文件。 【結束語】在大型數據庫中，索引是提升速度的一個關鍵因素。無論表的結構是多麼簡單，一次500000行的表掃描操做不管如何不會快。若是你的網站上也有 這種大規模的表，那麼你確實應該花些時間去分析能夠採用哪些索引，並考慮是否能夠改寫查詢以優化應用。要了解更多信息，請參見MySQL manual。另外注意，本文假定你所使用的MySQL是3.23版，部分查詢不能在3.22版MySQL上執行。