索引在數據庫中的地位是及其的重要，同時要想完全的掌握索引并不是一件容易的事，需要對數據的查詢原理以及計算機操作系統有深刻的認識，當然相關的算法和數據結構也是必須的。因此，這篇文章感到了一些壓力，不過還是決定先拿出來總結一下，理一理索引，就當做學習筆記了。

索引的重要習性猶如一本字典的拼音檢索和部首檢索部分，想象一下你買了一本只有正文的字典，那該有多么抓狂。而且在一個軟件系統中，通常數據的查詢與修改往往占到了10:1的比例，也就是我們需要將大部分的精力投入到數據的查詢上，其中很多工作是用來提升查詢的速度的，那么在這個過程中索引就扮演者非常重要的角色。

索引的實質

如果說一本字典的正文內容的實質是紙張的話，那么它前面按照拼音或者部首檢索的索引的實質是什么呢!當然也是紙張了，可能有人覺得是廢話，當我們同時類比到索引上就可以知道，一個數據表的實質是數據文件（即文件），那么索引的實質也當然是文件了，Mysql的InnoDB的數據表中的索引就是表空間的一部分。因此，初學者可以把索引完全想象成為一本字典，一本字典就是一個數據表，正文部分呢，就是這個數據表的詳細內容，按照拼音和部首的檢索都是索引。 當我們通過索引查找一條數據項的時候就猶如通過拼音索引查找某一個字，當在索引中查找到那個字的時候，會根據右邊對應的頁碼找到那個字的解釋，同樣，MySQL的索引工作原理也是如此，每個索引項都有一個建索引列的關鍵字和一個指向該數據項的指針（類似字典中的頁碼），當我們查找到那個目標關鍵字時，根據指針便可以直接定位到數據表中該關鍵字的位置。

但現實中的真是數據表并不像字典那樣，內容都是嚴格按照拼音序列排列的，因為有很多不確定的新內容要插入或者要進行其他操作，所以字典只是一種特殊的數據表，并不能把所有的數據表都拿來和字典比，這里用字典來類比只是為了對索引的實質有一個立體的認識。

索引是如何實現快速查找的

假設A公司有1024名員工（員工編號1-1024），早上的出勤人數為1023次，現在想知道員工編號為8的小明是否出勤，如何通過早上的簽到表快速的查詢小明是否出勤呢！在沒有索引的情況下，通常的做法是從第一條記錄逐個向后查找，如果小明最后一個來或者沒有來，那么就需要查找1023次，效率為O(N)。也許會覺得1023次查找對現在的計算機根本不算什么，但是對于很多系統動輒都是上千萬的數據記錄，你可以想象查找的時間，比如你用15分鐘終于通過了qq的身份校驗登陸上了qq是一種怎么樣的體驗。因此，索引就呼之欲出了，我們如何通過索引來提高一個數量級的查找效率，這個時候就需要對這1024條數據做些什么了，在每條記錄插入的時候，可以根據每條記錄的員工編號和存儲該記錄的地址（指針）建立一個二叉查找樹，這樣1023條記錄便可以通過10次查找便可查到，查找效率足足提高了100倍。

同樣，為了效率的提升，也付出了一些代價，因為建立二叉查找樹需要額外的存儲空間，同時每次插入數據的時候需要對二叉查找樹進行維護，減緩了數據的更新速度。但綜合來考慮，一般認為這樣做是值得的。

當然在MySQL中，不是采用的二叉樹查找樹來完成索引的存儲的，上面舉得例子只是為了說明索引的工作過程，但其思想是相同的。MySQL中沒有特殊說明的話，一般說的索引指的就是B-Tree索引，采用B-Tree這種數據結構是綜合了計算機操作系統以及組成而綜合考慮的。其核心思想主要是減少磁盤的IO次數，提高查詢速度。

如何理解聚簇索引

你只需記住它的名字叫聚簇索引，它不同于其他普通的索引！聚簇索引不僅僅是一種索引，更是一種存儲方式，InnoDB中將B-Tree索引和數據行存儲在一個數據結構中，意味著什么呢？這意味著數據行即索引，索引即數據行，它們是在一起，在一起，在一起的。

接著通過來建立字典的例子來理解聚簇索引和其他普通索引的區別，現在要建立一本中華字典，這個時候字典是空的，要我們造一本字典出來，首先我們要完成字典的正文，我們按照漢語拼音的順序去組織字典的正文，第一個是“安 an ”，放在一個位置，同時后面附加上注釋(這里，“an”就相當于聚簇索引的關鍵字，而后面的注釋就是數據行，它們存在一起)，第二個是“王 wang”字，通過和“安 an”字比較，拼音順序靠后，所以放第二個。注意這里的放是指存儲在磁盤中的位置，可以理解為存儲順序。第三個字是“小 xiao”字，通過拼音順序，需要將第三個字存在第一個字“安”后面，那“王”字已經占了磁盤頁面的位置，所以它需要向后面移動，如果移出該列，就導致了也分裂，所以可以看到聚集索引的更新代價真的很大，那為什么還要這樣做呢？聚簇索引帶來了那些好處？

......，假設按照上面方法已經建立好了字典的正文內容，這個時候就可以讓我們體會一下聚簇索引的好處了，假如你要找“安 an”字，根據拼音序列，你一定知道它一定在前幾個頁面，所以直接可以翻到前面，同時你也可以找到拼音“an”所對應的所有的漢字，這就是聚簇索引帶來的好處，同時聚簇索引是和數據行放在一起的，你不需要在根據索引里的指針找到對應的數據行，然后翻頁找到（翻頁就相當于磁盤IO），這些都是效率的提升。然而，上面也看到了聚簇索引的負面影響比如插入的時候，因此它就像一般利劍，用的合適效率提升，用的糟糕也會帶來很大的不好影響。

是時候區別一下非聚聚索引了，這個時候我們又按照部首建立了一個索引，那么按照部首建立的索引就是非聚簇索引，它單獨的存在在字典的前幾個頁面，而且同一個部首的字所對應的頁碼也是沒有順序的，如果我們要山字旁所對應的所有漢字，那就要取很多個頁面的值，導致很多隨機IO產生，同時不能很好利用計算機存儲系統的緩存系統，因此效率遠沒有聚簇索引高。

InnoDB中聚簇索引產生的原則：

• 當有主鍵時，主鍵為聚簇索引
• 當沒有主鍵時，引擎會選擇一個唯一的*非空*列來作為聚簇索引
• 如果沒有以上兩種情況的列，引擎會隱式的定義一個主鍵作為聚簇索引

最后，通過建立一個數據表來感受聚簇索引，首先建立有一個沒有主鍵也沒有唯一非空列索引的數據表，即聚簇索引是系統隱式生成這種情況。這種情況，一般就是按數據插入的先后順序進行排列。

CREATE TABLE user_log (
user_id INT NOT NULL,
place VARCHAR(20) NOT  NULL DEFAULT '',
login_time TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
 
) DEFAULT CHARSET utf8;

接下來插入三條數據：

> INSERT INTO user_log(user_id,place)
VALUES('1','中國');
> INSERT INTO user_log(user_id,place)
VALUES('2','中國');
> INSERT INTO user_log(user_id,place)
VALUES('1','美國');

然后，選擇所有列（即按照存儲順序查看數據列），果然如我們猜想，是按照插入順序存儲的：

>   SELECT * FROM user_log;
 
user_id place   login_time
1   中國  2015-11-20 10:32:41
2   中國  2015-11-20 10:33:18
1   美國  2015-11-20 10:33:18

接下來，我們添加一個唯一的索引（ID+login_time），此時 系統引擎應該將此索引作為聚簇索引，因此我們再次插入新的數據的時候是按照ID聚簇存儲的，就是說ID相同的會存儲在一起，存儲在同一個頁面，甚至連續的幾個頁面。 下面首先添加這個唯一索引 并接著添加三條新的記錄：

> ALTER TABLE user_log ADD UNIQUE KEY U_USER_LOG_ID_LOGIN_TIME(user_id,login_time);
 
> INSERT INTO user_log(user_id,place)
VALUES('1','法國');
> INSERT INTO user_log(user_id,place)
VALUES('2','日本');
> INSERT INTO user_log(user_id,place)
VALUES('1','韓國');

然后接著查看數據的存儲情況：

>   SELECT * FROM user_log;
 
user_id place   login_time
1   中國  2015-11-20 10:32:41
1   美國  2015-11-20 10:33:18
1   法國  2015-11-20 10:48:00
2   中國  2015-11-20 10:33:18
2   日本  2015-11-20 10:48:00

這樣以來，如果我們要獲取某一個用戶的登陸情況，就可以非常的方便，因為該用戶的所有登陸記錄是按照ID聚集的存儲在一起的，這樣主存緩存一個頁面的數據可能就OK了，如果是非聚集存儲的，假如某個id的數據分散在100個頁面，那么主存就要緩存這100個頁面，效率可想而知。

總結

這篇文中一開始的構想是想從計算機操作系統的存儲系統和B-Tree入手寫的，結果寫著寫著發現，有點不太現實，一來文章長度可能增加幾倍，二來可能自己都寫暈了，既然是小白篇嘛，就先來個綜述吧！總之索引是非常強大而且有意思的，然而當數據量達到一定量時，感覺索引也是有點乏力，但是盡量用好每一個索引是非常有必要而且是一種態度。