引言
回想四年前，我在學習mysql的索引這塊的時候，老師在講索引的時候，是像下面這麼說的html
索引就像一本書的目錄。而當用戶經過索引查找數據時，就比如用戶經過目錄查詢某章節的某個知識點。這樣就幫助用戶有效地提升了查找速度。因此，使用索引能夠有效地提升數據庫系統的總體性能。mysql
嗯，這麼說其實也對。可是呢，你們看完這種說法，其實可能仍是以爲太抽象了！所以呢，我還想再深刻的細說一下，因此就有了此文！
須要說明的是，我說的內容只在Mysql的Innodb引擎中是成立的。在Sql Server、oracle、Mysql的Mysiam引擎中的正確性，不必定成立！
OK，廢話很少說，開始囉嗦!
sql
正文
索引的科普
先引進聚簇索引和非聚簇索引的概念！
咱們平時在使用的Mysql中，使用下述語句
數據庫
CREATE [UNIQUE|FULLTEXT|SPATIAL] INDEX index_name
[USING index_type]
ON tbl_name (index_col_name,...)
index_col_name:
col_name [(length)] [ASC | DESC]
建立的索引，如複合索引、前綴索引、惟一索引，都是屬於非聚簇索引，在有的書籍中，又將其稱爲輔助索引(secondary index)。在後文中，咱們稱其爲非聚簇索引，其數據結構爲B+樹。數據結構
那麼，這個聚簇索引，在Mysql中是沒有語句來另外生成的。在Innodb中，Mysql中的數據是按照主鍵的順序來存放的。那麼聚簇索引就是按照每張表的主鍵來構造一顆B+樹，葉子節點存放的就是整張表的行數據。因爲表裏的數據只能按照一顆B+樹排序，所以一張表只能有一個聚簇索引。oracle
在Innodb中，聚簇索引默認就是主鍵索引。
這個時候，機智的讀者，應該要問我
性能
若是個人表沒建主鍵呢？學習
回答是，若是沒有主鍵，則按照下列規則來建聚簇索引ui
- 沒有主鍵時，會用一個惟一且不爲空的索引列作爲主鍵，成爲此表的聚簇索引
- 若是沒有這樣的索引，InnoDB會隱式定義一個主鍵來做爲聚簇索引。
ps:你們還記得，自增主鍵和uuid做爲主鍵的區別麼？因爲主鍵使用了聚簇索引，若是主鍵是自增id，，那麼對應的數據必定也是相鄰地存放在磁盤上的，寫入性能比較高。若是是uuid的形式，頻繁的插入會使innodb頻繁地移動磁盤塊，寫入性能就比較低了。spa
索引原理介紹
先來一張帶主鍵的表，以下所示，pId是主鍵
| pId | name | birthday |
|---|---|---|
| 5 | zhangsan | 2016-10-02 |
| 8 | lisi | 2015-10-04 |
| 11 | wangwu | 2016-09-02 |
| 13 | zhaoliu | 2015-10-07 |
畫出該表的結構圖以下
如上圖所示，分爲上下兩個部分，上半部分是由主鍵造成的B+樹，下半部分就是磁盤上真實的數據！那麼，當咱們， 執行下面的語句
select * from table where pId='11'
那麼，執行過程以下
如上圖所示，從根開始，通過3次查找，就能夠找到真實數據。若是不使用索引，那就要在磁盤上，進行逐行掃描，直到找到數據位置。顯然，使用索引速度會快。可是在寫入數據的時候，須要維護這顆B+樹的結構，所以寫入性能會降低！
OK，接下來引入非聚簇索引!咱們執行下面的語句
create index index_name on table(name);
此時結構圖以下所示
你們注意看，會根據你的索引字段生成一顆新的B+樹。所以， 咱們每加一個索引，就會增長表的體積， 佔用磁盤存儲空間。然而，注意看葉子節點，非聚簇索引的葉子節點並非真實數據，它的葉子節點依然是索引節點，存放的是該索引字段的值以及對應的主鍵索引(聚簇索引)。
若是咱們執行下列語句
select * from table where name='lisi'
此時結構圖以下所示
經過上圖紅線能夠看出，先從非聚簇索引樹開始查找，而後找到聚簇索引後。根據聚簇索引，在聚簇索引的B+樹上，找到完整的數據！
那
什麼狀況不去聚簇索引樹上查詢呢？
還記得咱們的非聚簇索引樹上存着該索引字段的值麼。若是，此時咱們執行下面的語句
select name from table where name='lisi'
此時結構圖以下
如上圖紅線所示，若是在非聚簇索引樹上找到了想要的值，就不會去聚簇索引樹上查詢。還記得，博主在《select的正確姿式》提到的索引問題麼：
當執行select col from table where col = ?，col上有索引的時候，效率比執行select * from table where col = ? 速度快好幾倍！
看完上面的圖，你應該對這句話有更深層的理解了。
那麼這個時候，咱們執行了下述語句，又會發生什麼呢？
create index index_birthday on table(birthday);
此時結構圖以下
看到了麼，多加一個索引，就會多生成一顆非聚簇索引樹。所以，不少文章才說，索引不能亂加。由於，有幾個索引，就有幾顆非聚簇索引樹！你在作插入操做的時候，須要同時維護這幾顆樹的變化！所以，若是索引太多，插入性能就會降低!
總結
講到這裏，你們應該清楚的明白索引的原理了！可能細節方面還不夠嚴謹，可是我以爲一個研發，理解到這裏能夠了，夠用了，畢竟咱們也不是專業的DBA。 但願你們有所收穫！