mysql的索引

索引的本質

MySQL官方對索引的定義爲：索引（Index）是幫助MySQL高效獲取數據的數據結構。提取句子主幹，就能夠獲得索引的本質：索引是數據結構。

咱們知道，數據庫查詢是數據庫的最主要功能之一。咱們都但願查詢數據的速度能儘量的快，所以數據庫系統的設計者會從查詢算法的角度進行優化。最基本的查詢算法固然是順序查找（linear search），這種複雜度爲O(n)的算法在數據量很大時顯然是糟糕的，好在計算機科學的發展提供了不少更優秀的查找算法，例如二分查找（binary search）、二叉樹查找（binary tree search）等。若是稍微分析一下會發現，每種查找算法都只能應用於特定的數據結構之上，例如二分查找要求被檢索數據有序，而二叉樹查找只能應用於二叉查找樹上，可是數據自己的組織結構不可能徹底知足各類數據結構（例如，理論上不可能同時將兩列都按順序進行組織），因此，在數據以外，數據庫系統還維護着知足特定查找算法的數據結構，這些數據結構以某種方式引用（指向）數據，這樣就能夠在這些數據結構上實現高級查找算法。這種數據結構，就是索引。

看一個例子：

圖1

圖1展現了一種可能的索引方式。左邊是數據表，一共有兩列七條記錄，最左邊的是數據記錄的物理地址（注意邏輯上相鄰的記錄在磁盤上也並非必定物理相鄰的）。爲了加快Col2的查找，能夠維護一個右邊所示的二叉查找樹，每一個節點分別包含索引鍵值和一個指向對應數據記錄物理地址的指針，這樣就能夠運用二叉查找在O(log2n)的複雜度內獲取到相應數據。

雖然這是一個貨真價實的索引，可是實際的數據庫系統幾乎沒有使用二叉查找樹或其進化品種紅黑樹（red-black tree）實現的，緣由會在下文介紹。

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

先從B-Tree分析，根據B-Tree的定義，可知檢索一次最多須要訪問h個節點。數據庫系統的設計者巧妙利用了磁盤預讀原理，將一個節點的大小設爲等於一個頁，這樣每一個節點只須要一次I/O就能夠徹底載入。爲了達到這個目的，在實際實現B-Tree還須要使用以下技巧：

每次新建節點時，直接申請一個頁的空間，這樣就保證一個節點物理上也存儲在一個頁裏，加之計算機存儲分配都是按頁對齊的，就實現了一個node只需一次I/O。

B-Tree中一次檢索最多須要h-1次I/O（根節點常駐內存），漸進複雜度爲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))   floor表示向下取整。因爲B+Tree內節點去掉了data域，所以能夠擁有更大的出度，擁有更好的性能。