資料庫索引總結

資料庫索引多採用b+tree,也有hash索引。

b+ tree索引和hash索引區別雜湊索引適合等值查詢，但是不無法進行範圍查詢雜湊索引沒辦法利用索引完成排序雜湊索引不支援多列聯合索引的最左匹配規則如果有大量重複鍵值得情況下，雜湊索引的效率會很低，因為存在雜湊碰撞問題

索引簡單論述的文章

innodb的b+ tree可能儲存的是整行資料，也有可能是主鍵的值。

在 innodb 裡，索引b+ tree的葉子節點儲存了整行資料的是主鍵索引，也被稱之為聚簇索引。而索引b+ tree的葉子節點儲存了主鍵的值的是非主鍵索引，也被稱之為非聚簇索引。主鍵索引樹的葉子節點直接就是我們要查詢的整行資料了。而非主鍵索引的葉子節點是主鍵的值，查到主鍵的值以後，還需要再通過主鍵的值再進行一次查詢（所謂回表）。

當然可以通過建立聯合索引減少回表，其實就是要取的字段建立索引，從非聚簇索引直接查詢到。覆蓋索引覆蓋索引（covering index）指乙個查詢語句的執行只用從索引中就能夠取得，不必從資料表中讀取。也可以稱之為實現了索引覆蓋。當一條查詢語句符合覆蓋索引條件時，mysql只需要通過索引就可以返回查詢所需要的資料，這樣避免了查到索引後再返回表操作，減少i/o提高效率。如，表covering_index_sample中有乙個普通索引 idx_key1_key2(key1,key2)。當我們通過sql語句：select key2 from covering_index_sample where key1 = 『keytest』;的時候，就可以通過覆蓋索引查詢，無需回表。

為什麼關係型資料庫都用b-tree不用二叉樹？

在建立多列索引時，我們根據業務需求，where子句中使用最頻繁的一列放在最左邊，因為mysql索引查詢會遵循最左字首匹配的原則，即最左優先，在檢索資料時從聯合索引的最左邊開始匹配。所以當我們建立乙個聯合索引的時候，如(key1,key2,key3)，相當於建立了（key1）、(key1,key2)和(key1,key2,key3)三個索引，這就是最左匹配原則。

最左匹配原則詳解

index condition pushdown（索引下推）mysql 5.6引入了索引下推優化，預設開啟，使用set optimizer_switch = 『index_condition_pushdown=off』;可以將其關閉。官方文件中給的例子和解釋如下： people表中（zipcode，lastname，firstname）構成乙個索引

select * from people where zipcode=『95054』 and lastname like 『%etrunia%』 and address like 『%main street%』;

如果沒有使用索引下推技術，則mysql會通過zipcode='95054』從儲存引擎中查詢對應的資料，返回到mysql服務端，然後mysql服務端基於lastname like '%etrunia%'和address like '%main street%'來判斷資料是否符合條件。如果使用了索引下推技術，則mysql首先會返回符合zipcode='95054』的索引，然後根據lastname like '%etrunia%'和address like '%main street%'來判斷索引是否符合條件。如果符合條件，則根據該索引來定位對應的資料，如果不符合，則直接reject掉。有了索引下推優化，可以在有like條件查詢的情況下，減少回表次數。

查詢優化器一條sql語句的查詢，可以有不同的執行方案，至於最終選擇哪種方案，需要通過優化器進行選擇，選擇執行成本最低的方案。在一條單錶查詢語句真正執行之前，mysql的查詢優化器會找出執行該語句所有可能使用的方案，對比之後找出成本最低的方案。這個成本最低的方案就是所謂的執行計畫。優化過程大致如下： 1、根據搜尋條件，找出所有可能使用的索引 2、計算全表掃瞄的代價 3、計算使用不同索引執行查詢的代價 4、對比各種執行方案的代價，找出成本最低的那乙個

索引詳細知識

資料庫索引總結

資料庫索引總結

資料庫索引總結

資料庫總結二索引

相關推薦