mysql數據庫索引結構及算法原理

mysql數據庫索引結構及算法原理

1.摘要

mysql數據庫支持多引擎，而各種引擎對索引的支持也各不相同，因此mysql支持多種索引類型，如BTree索引，哈希索引，全文索引等等。

2.數據結構及算法基礎

索引的本質

官方定義：索引是幫助mysql高效獲取數據的數據結構。
數據查詢是數據庫最主要的功能之一，查詢算法也有很多，但是每種算法都對被檢索的數據有一定的要求，即要在特定的數據結構上才能發揮它最好的效果，如二分查找要求數據有序。但是 數據庫中表的記錄有多行，理論上不可能同時將多列按照要求都按順序進行組織。
所以，在數據庫表之外，數據庫系統還維護着滿足特定查找算法的數據結構，這些數據結構以某種方式指向數據，這樣就可以在這數據上實現高級查找算法。這種數據結構，就是索引。
如下示例：

左邊是數據表，一共有兩列七條記錄，最左邊的是數據記錄的物理地址（注意邏輯上相鄰的記錄在磁盤上也並不是一定物理相鄰的）。爲了加快Col2的查找，可以維護一個右邊所示的二叉查找樹，每個節點分別包含索引鍵值和一個指向對應數據記錄物理地址的指針，這樣就可以運用二叉查找在O(log2n)O(log2n)的複雜度內獲取到相應數據。
雖然這是一個貨真價實的索引，但是實際的數據庫系統幾乎沒有使用二叉查找樹或其進化品種紅黑樹（red-black tree）實現的，原因會在下文介紹。

B-Tree和B+Tree

目前大部分數據庫系統及文件系統都採用B-Tree或其變種B+Tree作爲索引結構，在本文的下一節會結合存儲器原理及計算機存取原理討論爲什麼B-Tree和B+Tree在被如此廣泛用於索引，這一節先單純從數據結構角度描述它們。

B-Tree原理

B+Tree原理

B+樹是B-樹的變體，也是一種多路搜索樹
B+的特性：
1.所有關鍵字都出現在葉子結點的鏈表中（稠密索引），且鏈表中的關鍵字恰好
是有序的；
2.不可能在非葉子結點命中；
3.非葉子結點相當於是葉子結點的索引（稀疏索引），葉子結點相當於是存儲
（關鍵字）數據的數據層；
4.更適合文件索引系統；
MySQL就普遍使用B+Tree實現其索引結構
一般在數據庫系統或文件系統中使用的B+Tree結構都在經典B+Tree的基礎上進行了優化，增加了順序訪問指針。
做這個優化的目的是爲了提高區間訪問的性能，例如圖4中如果要查詢key爲從18到49的所有數據記錄，當找到18後，只需順着節點和指針順序遍歷就可以一次性訪問到所有數據節點，極大提到了區間查詢效率。

爲什麼使用B-Tree（B+Tree）

一般來說，索引本身也很大，不可能全部存儲在內存中，因此索引往往以索引文件的形式存儲的磁盤上。這樣的話，索引查找過程中就要產生磁盤I/O消耗，相對於內存存取，I/O存取的消耗要高几個數量級，所以評價一個數據結構作爲索引的優劣最重要的指標就是在查找過程中磁盤I/O操作次數的漸進複雜度。換句話說，索引的結構組織要儘量減少查找過程中磁盤I/O的存取次數。下面先介紹內存和磁盤存取原理，然後再結合這些原理分析B-/+Tree作爲索引的效率。

主存存取原理

目前計算機使用的主存基本都是隨機讀寫存儲器（RAM），現代RAM的結構和存取原理比較複雜，這裏本文拋卻具體差別，抽象出一個十分簡單的存取模型來說明RAM的工作原理。

從抽象角度看，主存是一系列的存儲單元組成的矩陣，每個存儲單元存儲固定大小的數據。每個存儲單元有唯一的地址，現代主存的編址規則比較複雜，這裏將其簡化成一個二維地址：通過一個行地址和一個列地址可以唯一定位到一個存儲單元。圖5展示了一個4 x 4的主存模型。
主存的存取過程如下：
當系統需要讀取主存時，則將地址信號放到地址總線上傳給主存，主存讀到地址信號後，解析信號並定位到指定存儲單元，然後將此存儲單元數據放到數據總線上，供其它部件讀取。
寫主存的過程類似，系統將要寫入單元地址和數據分別放在地址總線和數據總線上，主存讀取兩個總線的內容，做相應的寫操作。
這裏可以看出，主存存取的時間僅與存取次數呈線性關係，因爲不存在機械操作，兩次存取的數據的“距離”不會對時間有任何影響，例如，先取A0再取A1和先取A0再取D3的時間消耗是一樣的。

磁盤存取原理

上文說過，索引一般以文件形式存儲在磁盤上，索引檢索需要磁盤I/O操作。與主存不同，磁盤I/O存在機械運動耗費，因此磁盤I/O的時間消耗是巨大的。下圖是磁盤的整體結構示意圖。

一個磁盤由大小相同且同軸的圓形盤片組成，磁盤可以轉動（各個磁盤必須同步轉動）。在磁盤的一側有磁頭支架，磁頭支架固定了一組磁頭，每個磁頭負責存取一個磁盤的內容。磁頭不能轉動，但是可以沿磁盤半徑方向運動（實際是斜切向運動），每個磁頭同一時刻也必須是同軸的，即從正上方向下看，所有磁頭任何時候都是重疊的（不過目前已經有多磁頭獨立技術，可不受此限制）。
盤片被劃分成一系列同心環，圓心是盤片中心，每個同心環叫做一個磁道，所有半徑相同的磁道組成一個柱面。磁道被沿半徑線劃分成一個個小的段，每個段叫做一個扇區，每個扇區是磁盤的最小存儲單元。爲了簡單起見，我們下面假設磁盤只有一個盤片和一個磁頭。
當需要從磁盤讀取數據時，系統會將數據邏輯地址傳給磁盤，磁盤的控制電路按照尋址邏輯將邏輯地址翻譯成物理地址，即確定要讀的數據在哪個磁道，哪個扇區。爲了讀取這個扇區的數據，需要將磁頭放到這個扇區上方，爲了實現這一點，磁頭需要移動對準相應磁道，這個過程叫做尋道，所耗費時間叫做尋道時間，然後磁盤旋轉將目標扇區旋轉到磁頭下，這個過程耗費的時間叫做旋轉時間。
局部性原理與磁盤預讀

由於存儲介質的特性，磁盤本身存取就比主存慢很多，再加上機械運動耗費，磁盤的存取速度往往是主存的幾百分分之一，因此爲了提高效率，要儘量減少磁盤I/O。爲了達到這個目的，磁盤往往不是嚴格按需讀取，而是每次都會預讀，即使只需要一個字節，磁盤也會從這個位置開始，順序向後讀取一定長度的數據放入內存。這樣做的理論依據是計算機科學中著名的局部性原理：
當一個數據被用到時，其附近的數據也通常會馬上被使用。
程序運行期間所需要的數據通常比較集中。
由於磁盤順序讀取的效率很高（不需要尋道時間，只需很少的旋轉時間），因此對於具有局部性的程序來說，預讀可以提高I/O效率。
預讀的長度一般爲頁（page）的整倍數。頁是計算機管理存儲器的邏輯塊，硬件及操作系統往往將主存和磁盤存儲區分割爲連續的大小相等的塊，每個存儲塊稱爲一頁（在許多操作系統中，頁得大小通常爲4k），主存和磁盤以頁爲單位交換數據。當程序要讀取的數據不在主存中時，會觸發一個缺頁異常，此時系統會向磁盤發出讀盤信號，磁盤會找到數據的起始位置並向後連續讀取一頁或幾頁載入內存中，然後異常返回，程序繼續運行。

B-/+Tree索引的性能分析

到這裏終於可以分析B-/+Tree索引的性能了。
上文說過一般使用磁盤I/O次數評價索引結構的優劣。先從B-Tree分析，根據B-Tree的定義，可知檢索一次最多需要訪問h個節點。數據庫系統的設計者巧妙利用了磁盤預讀原理，將一個節點的大小設爲等於一個頁，這樣每個節點只需要一次I/O就可以完全載入。爲了達到這個目的，在實際實現B-Tree還需要使用如下技巧：
每次新建節點時，直接申請一個頁的空間，這樣就保證一個節點物理上也存儲在一個頁裏，加之計算機存儲分配都是按頁對齊的，就實現了一個node只需一次I/O。
B-Tree中一次檢索最多需要h-1次I/O（根節點常駐內存），漸進複雜度爲O(h)=O(logdN)O(h)=O(logdN)。一般實際應用中，出度d是非常大的數字，通常超過100，因此h非常小（通常不超過3）。
綜上所述，用B-Tree作爲索引結構效率是非常高的。
而紅黑樹這種結構，h明顯要深的多。由於邏輯上很近的節點（父子）物理上可能很遠，無法利用局部性，所以紅黑樹的I/O漸進複雜度也爲O(h)，效率明顯比B-Tree差很多。
上文還說過，B+Tree更適合外存索引，原因和內節點出度d有關。從上面分析可以看到，d越大索引的性能越好，而出度的上限取決於節點內key和data的大小：
dmax=floor(pagesize/(keysize+datasize+pointsize))dmax=floor(pagesize/(keysize+datasize+pointsize))
floor表示向下取整。由於B+Tree內節點去掉了data域，因此可以擁有更大的出度，擁有更好的性能。

mysql索引的實現

在MySQL中，索引屬於存儲引擎級別的概念，不同存儲引擎對索引的實現方式是不同的，本文主要討論MyISAM和InnoDB兩個存儲引擎的索引實現方式。

MyISAM引擎的索引實現

MyISAM引擎使用B+Tree作爲索引結構，葉節點的data域存放的是數據記錄的地址。如下圖所示：

這裏設表一共有三列，假設我們以Col1爲主鍵，則圖8是一個MyISAM表的主索引（Primary key）示意。可以看出MyISAM的索引文件僅僅保存數據記錄的地址。在MyISAM中，主索引和輔助索引（Secondary key）在結構上沒有任何區別，只是主索引要求key是唯一的，而輔助索引的key可以重複。
如果我們在Col2上建立一個輔助索引，則此索引的結構如下圖所示。

同樣也是一顆B+Tree，data域保存數據記錄的地址。因此，MyISAM中索引檢索的算法爲首先按照B+Tree搜索算法搜索索引，如果指定的Key存在，則取出其data域的值，然後以data域的值爲地址，讀取相應數據記錄。
MyISAM的索引方式也叫做“非聚集”的，之所以這麼稱呼是爲了與InnoDB的聚集索引區分。

InnoDB引擎的索引實現

雖然InnoDB也使用B+Tree作爲索引結構，但具體實現方式卻與MyISAM截然不同。
第一個重大區別是InnoDB的數據文件本身就是索引文件。從上文知道，MyISAM索引文件和數據文件是分離的，索引文件僅保存數據記錄的地址。而在InnoDB中，表數據文件本身就是按B+Tree組織的一個索引結構，這棵樹的葉節點data域保存了完整的數據記錄。這個索引的key是數據表的主鍵，因此InnoDB表數據文件本身就是主索引。

上圖是是InnoDB主索引（同時也是數據文件）的示意圖，可以看到葉節點包含了完整的數據記錄。這種索引叫做聚集索引。因爲InnoDB的數據文件本身要按主鍵聚集，所以InnoDB要求表必須有主鍵（MyISAM可以沒有），如果沒有顯式指定，則MySQL系統會自動選擇一個可以唯一標識數據記錄的列作爲主鍵，如果不存在這種列，則MySQL自動爲InnoDB表生成一個隱含字段作爲主鍵，這個字段長度爲6個字節，類型爲長整形。
第二個與MyISAM索引的不同是InnoDB的輔助索引data域存儲相應記錄主鍵的值而不是地址。換句話說，InnoDB的所有輔助索引都引用主鍵作爲data域。如下圖所示。

這裏以英文字符的ASCII碼作爲比較準則。聚集索引這種實現方式使得按主鍵的搜索十分高效，但是輔助索引搜索需要檢索兩遍索引：首先檢索輔助索引獲得主鍵，然後用主鍵到主索引中檢索獲得記錄。
瞭解不同存儲引擎的索引實現方式對於正確使用和優化索引都非常有幫助，例如知道了InnoDB的索引實現後，就很容易明白爲什麼不建議使用過長的字段作爲主鍵，因爲所有輔助索引都引用主索引，過長的主索引會令輔助索引變得過大。再例如，用非單調的字段作爲主鍵在InnoDB中不是個好主意，因爲InnoDB數據文件本身是一顆B+Tree，非單調的主鍵會造成在插入新記錄時數據文件爲了維持B+Tree的特性而頻繁的分裂調整，十分低效，而使用自增字段作爲主鍵則是一個很好的選擇。

索引使用策略及優化

MySQL的優化主要分爲結構優化（Scheme optimization）和查詢優化（Query optimization）。本章討論的高性能索引策略主要屬於結構優化範疇。本章的內容完全基於上文的理論基礎，實際上一旦理解了索引背後的機制，那麼選擇高性能的策略就變成了純粹的推理，並且可以理解這些策略背後的邏輯。

示例數據庫

爲了討論索引策略，需要一個數據量不算小的數據庫作爲示例。本文選用MySQL官方文檔中提供的示例數據庫之一：employees。這個數據庫關係複雜度適中，且數據量較大。下圖是這個數據庫的E-R關係圖（引用自MySQL官方手冊）

最左前綴原理與相關優化

高效使用索引的首要條件是知道什麼樣的查詢會使用到索引，這個問題和B+Tree中的“最左前綴原理”有關，下面通過例子說明最左前綴原理。
這裏先說一下聯合索引的概念。在上文中，我們都是假設索引只引用了單個的列，實際上，MySQL中的索引可以以一定順序引用多個列，這種索引叫做聯合索引，一般的，一個聯合索引是一個有序元組 < a1, a2, …, an >，其中各個元素均爲數據表的一列，實際上要嚴格定義索引需要用到關係代數，但是這裏我不想討論太多關係代數的話題，因爲那樣會顯得很枯燥，所以這裏就不再做嚴格定義。另外，單列索引可以看成聯合索引元素數爲1的特例。
以employees.titles表爲例，下面先查看其上都有哪些索引：

從結果中可以到titles表的主索引爲< emp_no, title, from_date >，還有一個輔助索引< emp_no >。爲了避免多個索引使事情變複雜（MySQL的SQL優化器在多索引時行爲比較複雜），這裏我們將輔助索引drop掉：

這樣就可以專心分析索引PRIMARY的行爲了。

情況一：全列匹配

很明顯，當按照索引中所有列進行精確匹配（這裏精確匹配指“=”或“IN”匹配）時，索引可以被用到。這裏有一點需要注意，理論上索引對順序是敏感的，但是由於MySQL的查詢優化器會自動調整where子句的條件順序以使用適合的索引，例如我們將where中的條件順序顛倒：

效果是一樣的。

情況二：最左前綴匹配

當查詢條件精確匹配索引的左邊連續一個或幾個列時，如< emp_no >或< emp_no, title >，所以可以被用到，但是隻能用到一部分，即條件所組成的最左前綴。上面的查詢從分析結果看用到了PRIMARY索引，但是key_len爲4，說明只用到了索引的第一列前綴。

情況三：查詢條件用到了索引中列的精確匹配，但是中間某個條件未提供

此時索引使用情況和情況二相同，因爲title未提供，所以查詢只用到了索引的第一列，而後面的from_date雖然也在索引中，但是由於title不存在而無法和左前綴連接，因此需要對結果進行掃描過濾from_date（這裏由於emp_no唯一，所以不存在掃描）。如果想讓from_date也使用索引而不是where過濾，可以增加一個輔助索引< emp_no, from_date >，此時上面的查詢會使用這個索引。除此之外，還可以使用一種稱之爲“隔離列”的優化方法，將emp_no與from_date之間的“坑”填上。
首先我們看下title一共有幾種不同的值：

只有7種。在這種成爲“坑”的列值比較少的情況下，可以考慮用“IN”來填補這個“坑”從而形成最左前綴：

這次key_len爲59，說明索引被用全了，但是從type和rows看出IN實際上執行了一個range查詢，這裏檢查了7個key。看下兩種查詢的性能比較：

“填坑”後性能提升了一點。如果經過emp_no篩選後餘下很多數據，則後者性能優勢會更加明顯。當然，如果title的值很多，用填坑就不合適了，必須建立輔助索引。

情況四：查詢條件沒有指定索引第一列

由於不是最左前綴，索引這樣的查詢顯然用不到索引。

情況五：匹配某列的前綴字符串。

此時可以用到索引，但是如果通配符不是隻出現在末尾，則無法使用索引。（原文表述有誤，如果通配符%不出現在開頭，則可以用到索引，但根據具體情況不同可能只會用其中一個前綴）

情況六：範圍查詢

範圍列可以用到索引（必須是最左前綴），但是範圍列後面的列無法用到索引。同時，索引最多用於一個範圍列，因此如果查詢條件中有兩個範圍列則無法全用到索引

可以看到索引對第二個範圍索引無能爲力。這裏特別要說明MySQL一個有意思的地方，那就是僅用explain可能無法區分範圍索引和多值匹配，因爲在type中這兩者都顯示爲range。同時，用了“between”並不意味着就是範圍查詢，例如下面的查詢

看起來是用了兩個範圍查詢，但作用於emp_no上的“BETWEEN”實際上相當於“IN”，也就是說emp_no實際是多值精確匹配。可以看到這個查詢用到了索引全部三個列。因此在MySQL中要謹慎地區分多值匹配和範圍匹配，否則會對MySQL的行爲產生困惑。

情況七：查詢條件中含有函數或表達式

很不幸，如果查詢條件中含有函數或表達式，則MySQL不會爲這列使用索引（雖然某些在數學意義上可以使用）。例如：

雖然這個查詢和情況五中功能相同，但是由於使用了函數left，則無法爲title列應用索引，而情況五中用LIKE則可以。再如：

顯然這個查詢等價於查詢emp_no爲10001的函數，但是由於查詢條件是一個表達式，MySQL無法爲其使用索引。看來MySQL還沒有智能到自動優化常量表達式的程度，因此在寫查詢語句時儘量避免表達式出現在查詢中，而是先手工私下代數運算，轉換爲無表達式的查詢語句。

InnoDB的主鍵選擇與插入優化

在使用InnoDB存儲引擎時，如果沒有特別的需要，請永遠使用一個與業務無關的自增字段作爲主鍵。

經常看到有帖子或博客討論主鍵選擇問題，有人建議使用業務無關的自增主鍵，有人覺得沒有必要，完全可以使用如學號或身份證號這種唯一字段作爲主鍵。不論支持哪種論點，大多數論據都是業務層面的。如果從數據庫索引優化角度看，使用InnoDB引擎而不使用自增主鍵絕對是一個糟糕的主意。

上文討論過InnoDB的索引實現，InnoDB使用聚集索引，數據記錄本身被存於主索引（一顆B+Tree）的葉子節點上。這就要求同一個葉子節點內（大小爲一個內存頁或磁盤頁）的各條數據記錄按主鍵順序存放，因此每當有一條新的記錄插入時，MySQL會根據其主鍵將其插入適當的節點和位置，如果頁面達到裝載因子（InnoDB默認爲15/16），則開闢一個新的頁（節點）。
如果表使用自增主鍵，那麼每次插入新的記錄，記錄就會順序添加到當前索引節點的後續位置，當一頁寫滿，就會自動開闢一個新的頁。如下圖所示：

這樣就會形成一個緊湊的索引結構，近似順序填滿。由於每次插入時也不需要移動已有數據，因此效率很高，也不會增加很多開銷在維護索引上。
如果使用非自增主鍵（如果身份證號或學號等），由於每次插入主鍵的值近似於隨機，因此每次新紀錄都要被插到現有索引頁得中間某個位置：

此時MySQL不得不爲了將新記錄插到合適位置而移動數據，甚至目標頁面可能已經被回寫到磁盤上而從緩存中清掉，此時又要從磁盤上讀回來，這增加了很多開銷，同時頻繁的移動、分頁操作造成了大量的碎片，得到了不夠緊湊的索引結構，後續不得不通過OPTIMIZE TABLE來重建表並優化填充頁面。
因此，只要可以，請儘量在InnoDB上採用自增字段做主鍵。

索引的優缺點

優點：
1.大大加快數據的檢索速度;
2.創建唯一性索引，保證數據庫表中每一行數據的唯一性;
3.加速表和表之間的連接;
4.在使用分組和排序子句進行數據檢索時，可以顯著減少查詢中分組和排序的時間。
缺點：
1.索引需要佔用數據表以外的物理存儲空間
2.創建索引和維護索引要花費一定的時間
3.當對錶進行更新操作時，索引需要被重建，這樣降低了數據的維護速度。

索引的類型

根據數據庫的功能，可以在數據庫設計器中創建索引：唯一索引、主鍵索引和聚集索引。 儘管唯一索引有助於定位信息，但爲獲得最佳性能結果，建議改用主鍵或唯一約束。
唯一索引： UNIQUE 例如：create unique index stusno on student（sno）；
表明此索引的每一個索引值只對應唯一的數據記錄，對於單列惟一性索引，這保證單列不包含重複的值。對於多列惟一性索引，保證多個值的組合不重複。
主鍵索引： primary key
數據庫表經常有一列或列組合，其值唯一標識表中的每一行。該列稱爲表的主鍵。 在數據庫關係圖中爲表定義主鍵將自動創建主鍵索引，主鍵索引是唯一索引的特定類型。該索引要求主鍵中的每個值都唯一。當在查詢中使用主鍵索引時，它還允許對數據的快速訪問。
聚集索引（也叫聚簇索引）：cluster
在聚集索引中，表中行的物理順序與鍵值的邏輯（索引）順序相同。一個表只能包含一個聚集索引。 如果某索引不是聚集索引，則表中行的物理順序與鍵值的邏輯順序不匹配。與非聚集索引相比，聚集索引通常提供更快的數據訪問速度。

索引的實現方式

1 B+樹
我們經常聽到B+樹就是這個概念，用這個樹的目的和紅黑樹差不多，也是爲了儘量保持樹的平衡，當然紅黑樹是二叉樹，但B+樹就不是二叉樹了，節點下面可以有多個子節點，數據庫開發商會設置子節點數的一個最大值，這個值不會太小，所以B+樹一般來說比較矮胖，而紅黑樹就比較瘦高了。
關於B+樹的插入，刪除，會涉及到一些算法以保持樹的平衡，這裏就不詳述了。ORACLE的默認索引就是這種結構的。
如果經常需要同時對兩個字段進行AND查詢,那麼使用兩個單獨索引不如建立一個複合索引，因爲兩個單獨索引通常數據庫只能使用其中一個，而使用複合索引因爲索引本身就對應到兩個字段上的，效率會有很大提高。
2 散列索引
第二種索引叫做散列索引，就是通過散列函數來定位的一種索引，不過很少有單獨使用散列索引的，反而是散列文件組織用的比較多。
散列文件組織就是根據一個鍵通過散列計算把對應的記錄都放到同一個槽中，這樣的話相同的鍵值對應的記錄就一定是放在同一個文件裏了，也就減少了文件讀取的次數，提高了效率。
散列索引呢就是根據對應鍵的散列碼來找到最終的索引項的技術，其實和B樹就差不多了，也就是一種索引之上的二級輔助索引，我理解散列索引都是二級或更高級的稀疏索引，否則桶就太多了，效率也不會很高。
3 位圖索引
位圖索引是一種針對多個字段的簡單查詢設計一種特殊的索引，適用範圍比較小，只適用於字段值固定並且值的種類很少的情況，比如性別，只能有男和女，或者級別，狀態等等，並且只有在同時對多個這樣的字段查詢時才能體現出位圖的優勢。
位圖的基本思想就是對每一個條件都用0或者1來表示，如有5條記錄，性別分別是男，女，男，男，女，那麼如果使用位圖索引就會建立兩個位圖，對應男的10110和對應女的01001,這樣做有什麼好處呢，就是如果同時對多個這種類型的字段進行and或or查詢時，可以使用按位與和按位或來直接得到結果了。
B+樹最常用，性能也不差，用於範圍查詢和單值查詢都可以。特別是範圍查詢，非得用B+樹這種順序的纔可以了。
HASH的如果只是對單值查詢的話速度會比B+樹快一點，但是ORACLE好像不支持HASH索引，只支持HASH表空間。
位圖的使用情況很侷限，只有很少的情況才能用，一定要確定真正適合使用這種索引才用（值的類型很少並且需要複合查詢），否則建立一大堆位圖就一點意義都沒有了。

參考

【1】http://blog.codinglabs.org/articles/theory-of-mysql-index.html
【2】http://blog.csdn.net/sdgihshdv/article/details/75039825