数据库索引：引入
數據庫索引的通俗理解
為什么需要索引？
「索引就像書的目錄，通過書的目錄就準確的定位到了書籍具體的內容」，
數據在磁盤上是以塊的形式存儲的。為確保對磁盤操作的原子性，訪問數據的時候會一并訪問所有數據塊。磁盤上的這些數據塊與鏈表類似，即它們都包含一個數據段和一個指針，指針指向下一個節點（數據塊）的內存地址，而且它們都不需要連續存儲（即邏輯上相鄰的數據塊在物理上可以相隔很遠）。
舉個例子來講，我們有一個數據表User.為了簡便，這個表沒有主鍵。
?
| Identity | Name | Age | Grade |
| 1 | Robin | 28 | 90 |
| 5 | Lilei | 26 | 60 |
| 3 | Hanmei | 25 | 50 |
| 4 | Lucy | 27 | 66 |
| 2 | Lily | 29 | 80 |
?
雖然這些數據都存在于一個User表中，但是物理上，這些數據可能存儲在分散的數據塊中。
查找Lily這個人的信息,?已知Lily的Identity為2，?select* fromUser where?Identity= 2.
在查找的時候，首先找到這個表的第一條記錄所在的數據庫地址，然后發現Identity為1，并不是所需要的值，然后在這個數據庫的底端，找到了下一個數據塊的地址。（這個類似于鏈表），如此一來，查詢了5次才找到了所需要的值。（為了簡單起見，我們考慮Identity不能有重復值）
?
為了加快搜索速度，這里就出現了索引。索引是對某個字段進行排序的一種方式。對表中的某個字段建立索引會創建另一種數據結構，其中保存著字段的值，每個值又指向與它相關的記錄。這種索引的數據結構是經過排序的，因而可以對其執行二分查找。
?
對上個表的Identity字段進行索引，就是在數據庫存儲空間上創建一塊專用的控件，把User表的所有的Identity字段的值拿出來放到這里，并且對這些值進行排序，并且每個值都攜帶著這個Identity對應的行所在數據塊的地址。因為Identity是進過排序的，按照一定的數據結構存儲的，所以數據庫引擎在查找的時候，比如說查找identity為5，引擎就會計算，5大概在整個排序結構的大致地方，然后到那里去拿出這個值看看是不是，不是的話就再次相應的向左或者向右移動去尋找。（這里用到的知識都是大學時候的數據結構的知識，二分法查找，相對于毫無頭緒的一個一個的查找，二分法的查找速度明顯的提高，達到了log2 N，其實這有多快我也不明白，反正就記得當時學的時候，確實是比一般查找快多了。）
?
通俗的來講，就是根據你指定的列，建立一個遵循一定數據結構的區域，這些區域可以快速定位到相應數據庫字段所在的磁盤地址。
索引的好處是特別明顯的，那就是大大的提高了查詢的速度。但是相對應的也帶來了一些不好的地方。
第一，創建索引和維護索引要耗費時間，這種時間隨著數據量的增加而增加。
第二，索引需要占物理空間，除了數據表占數據空間之外，每一個索引還要占一定的物理空間，如果要建立聚簇索引，那么需要的空間就會更大。
第三，當對表中的數據進行增加、刪除和修改的時候，索引也要動態的維護，這樣就降低了數據的維護速度。
最后還有一點需要注意的是，我們在數據庫上對于某個字段建立了索引，那么什么情況下才走索引呢？
?
比如?select * from User where?Identity= 2?這條語句，是走索引查詢的。因為是否走索引取決于這條查詢語句的where子句。數據庫引擎發現你的where語句中有identity，那么就會從identity的索引數據結構中進行檢索。曾經看到有人說select *會降低檢索速度，這個跟索引沒關系，select *?降低檢索速度，是因為從數據庫服務器端到客戶端的網絡傳輸是有時間的，select *?中難免包含著不必要的字段，所以傳輸起來會比較慢。
上述講到了存儲索引用的是某種數據結構類型，接下來將說一下具體索引的存儲用到了什么數據結構的類型：
索引原理必須清楚一種數據結構「平衡樹」(非二叉)，也就是b tree或者 b+tree，重要的事情說三遍：“平衡樹，平衡樹，平衡樹”。當然，有的數據庫也使用哈希桶作用索引的數據結構，然而，主流的RDBMS都是把平衡樹當做數據表默認的索引數據結構的。
下一節詳細講解索引的底層數據結構?
總結
- 上一篇： Statement和PraparedSt
- 下一篇： MYSQL: MERGE引擎实现多分表的