什么是索引（Index）。數據庫中的索引sql時間區間查詢效率，就好??本書的目錄，它可以幫我們快速進行特定 值的定位與查找，從而加快數據查詢的效率。
索引就是幫助數據庫管理系統高效獲取數據的數據結構。
1、什么情況下創建索引，什么時候不需要索引？
2、索引的種類有哪些？
今天通過這篇文章讓你真正了解索引。
什么情況下創建索引，什么時候不需要索引？ 主鍵自動建立唯一索引 頻繁作為查詢條件的字段應該創建索引 查詢中排序的字段創建索引將大大提高排序的速度（索引就是排序加快速查找 查詢中統計或者分組的字段；頻繁更新的字段不適合創建索引，因為每次更新不單單是更新記錄，還會更新索引，保存索引文件where條件里用不到的字段，不創建索引；表記錄太少，不需要創建索引；經常增刪改的表；數據重復且分布平均的字段，因此為經常查詢的和經常排序的字段建立索引。注意某些數據包含大量重復數據，因此他建立索引就沒有太大的效果，例如性別字段，只有男女，不適合建立索引。索引的種類有哪些？
雖然使用索引的本質目的是幫我們快速定位想要查找的數據，但實際上，索引有很多種類。
從功能邏輯上說，索引主要有 4 種，分別是普通索引、唯?索引、主鍵索引和全文索引。
普通索引：最基本的索引，它沒有任何限制唯一索引：索引列的值必須唯一，且不能為空，如果是組合索引，則列值的組合必須唯一。主鍵索引：特殊的索引，唯一的標識一條記錄，不能為空，一般用 key來約束。全文索引：全文索引時將存儲在數據庫中的整本書或整篇文章中的任意內容信息查找出來的技術。它可以根據需要獲取全文中有關章，節，段，句，詞等信息，也可以進行各種統計和分析。
普通索引是基礎的索引，沒有任何約束，主要?于提?查詢效率。
唯?索引就是在普通索引的基礎上增加了數據 唯?性的約束，在?張數據表?可以有多個唯?索引。
主鍵索引在唯?索引的基礎上增加了不為空的約束，也就 是 NOT NULL，?張表?最多只有?個主鍵索引。
全?索引用的不多，MySQL自帶的全文索引只支持英文。我們通?？梢圆捎脤?的全?搜索引擎，?如 ES ) 和 Solr。
按照物理實現?式，索引可以分為 2 種：聚集索引和非聚集索引。我們也把聚集索引稱為?級索引或者輔助索引
什么是聚集索引和非聚集索引
聚集索引：類似字典正文內容本身就是一種按照一定規則排列的目錄
非聚集索引：這種目錄純粹是目錄，正文純粹是正文的排序方式
每個表只能有一個聚集索引，因為目錄只能按照一種方法進行排序 。
聚集索引與?聚集索引的原理不同，在使?上也有?些區別：
聚集索引的葉?節點存儲的就是我們的數據記錄，?聚集索引的葉?節點存儲的是數據位置。?聚集索引不 會影響數據表的物理存儲順序。 ?個表只能有?個聚集索引，因為只能有?種排序存儲的?式，但可以有多個?聚集索引，也就是多個索引目錄提供數據檢索。 使用聚集索引的時候，數據的查詢效率?，但如果對數據進?插?，刪除，更新等操作，效率會??聚集索引低。什么是 B 樹
B 樹的英?是 Tree，也就是平衡的多路 搜索樹，它的?度遠?于平衡?叉樹的?度。在?件系統和數據庫系統中的索引結構 經常采? B 樹來實現。
B 樹的結構如下圖所示：
什么是 B+ 樹
B+樹基于 B 樹做出了改進，主流的 DBMS 都?持 B+樹的索引?式，?如 MySQL。B+樹和 B 樹的差異在于以下?點：
有 k 個孩?的節點就有 k 個關鍵字。也就是孩子數量 = 關鍵字數，而B 樹中， 孩?數量 = 關鍵字數+1。 非葉子節點的關鍵字也會同時存在在?節點中，并且是在?節點中所有關鍵字的 最?（或最?）。 非葉子節點僅?于索引，不保存數據記錄，跟記錄有關的信息都放在葉子節點 中。? B 樹中，非葉子節點既保存索引，也保存數據記錄。 所有關鍵字都在葉子節點出現，葉子節點構成?個有序鏈表，?且葉子節點本? 按照關鍵字的大小從小到大順序鏈接。
下圖就是?棵 B+樹，階數為 3，根節點中的關鍵字 1、18、35 分別是?節點（1， 8，14），（18，24，31）和（35，41，53）中的最?值。每?層?節點的關鍵字都會出現在下?層的?節點的關鍵字中，因此在葉?節點中包括了所有的關鍵字信息，并且每?個葉?節點都有?個指向下?個節點的指針，這樣就形成了?個鏈表。
比如，我們想要查找關鍵字 16，B+ 樹會?頂向下逐層進行查找：
1、與根節點的關鍵字，（1，18，35）進??較，16 在 1 和 18 之間，得到指針 P1（指 向磁盤塊 2）
2、 找到磁盤塊 2，關鍵字為（1，8，14），因為 16 ?于 14，所以得到指針 P3（指向磁盤塊 7）
3、找到磁盤塊 7，關鍵字為（14，16，17），然后我們找到了關鍵字 16，所以可以 找到關鍵字 16 所對應的數據。
B+樹和 B 樹有個根本的差異在于，B+樹的中間節點并不直接存儲數據。?先，B+樹查詢效率更穩定。因為 B+樹每次只有訪問到葉?節點才能找到對應的數據sql時間區間查詢效率，?在 B 樹中，?葉?節點也會存儲數據，這樣就會造成查詢效率不穩定的情況，有時候訪問到了?葉?節點就可以找到關鍵字，?有時需要訪問到葉?節點才能找到 關鍵字。 其次，B 樹的查詢效率更?，這是因為通常 B 樹? B 樹更矮胖（階數更?，深度 更低），查詢所需要的磁盤 I/O 也會更少。同樣的磁盤???，B 樹可以存儲更多 的節點關鍵字。 不僅是對單個關鍵字的查詢上，在查詢范圍上，B 樹的效率也? B 樹?。這是因為 所有關鍵字都出現在 B 樹的葉?節點中，并通過有序鏈表進?了鏈接。?在 B 樹中 則需要通過中序遍歷才能完成查詢范圍的查找，效率要低很多。
哈希索引
哈希索引基本散列表實現，散列表（也稱哈希表）是根據關鍵碼值(Key value)而直接進行訪問的數據結構，它讓碼值經過哈希函數的轉換映射到散列表對應的位置上，查找效率非常高。假設我們對名字建立了哈希索引，則查找過程如下圖所示：
對于每一行數據，存儲引擎都會對所有的索引列（上圖中的 name 列）計算一個哈希碼（上圖散列表的位置），散列表里的每個元素指向數據行的指針，由于索引自身只存儲對應的哈希值，所以索引的結構十分緊湊，這讓哈希索引查找速度非?？?！當然了哈希表的劣勢也是比較明顯的，不支持區間查找，不支持排序，所以更多的時候哈希表是與 B Tree等一起使用的。
索引設計準則：三星索引
如果一個查詢滿足三星索引中三顆星的所有索引條件，理論上可以認為我們設計的索引是最好的索引。什么是三星索引
第一顆星：WHERE 后面參與查詢的列可以組成了單列索引或聯合索引第二顆星：避免排序，即如果 SQL 語句中出現 order by ，那么取出的結果集就已經是按照 排序好的，不需要再生成臨時表第三顆星： 對應的列應該盡量是索引列，即盡量避免回表查詢。
綜上所述，三星索引只是給我們構建索引提供了一個參考，索引設計應該盡量靠近三星索引的標準，但實際場景我們一般無法同時滿足三星索引，一般我們會優先選擇滿足第三顆星（因為回表代價較大）至于第一，二顆星就要依賴于實際的成本及實際的業務場景考慮。
總結
使?索引可以幫助我們從海量的數據中快速定位想要查找的數據，不過索引也存在?些不?，?如占?存儲空 間、降低數據庫寫操作的性能等，如果有多個索引還會增加索引選擇的時間。當我們使?索引時，需要平衡索引 的利（提升查詢效率）和弊（維護索引所需的代價）。
在實際?作中，我們還需要基于需求和數據本?的分布情況來確定是否使?索引，盡管索引不是萬能的，但數據 量?的時候不使?索引是不可想象的，畢竟索引的本質，是幫助我們提升數據檢索的效率。