轉 漫談數據庫索引

漫談數據庫索引

 

1、引言

2、B-Tree

B-TreeB+TreeMsSqlB+TreeOracleSysbaseB-TreeB-Tree 

不一樣於（二叉樹，最多有兩個子樹），一棵階的知足如下條件：

）每一個結點至多有個孩子；

）除根結點和葉結點外，其它每一個結點至少有個孩子；

）根結點至少有兩個孩子（除非該樹僅包含一個結點）；

）全部葉結點在同一層，葉結點不包含任何關鍵字信息；

）有個關鍵字的非葉結點剛好包含個孩子；

B-TreeM=4 

Key[]Son[]B-TreeKey[]KKKey[]KKey[i]Key[i+1]Son[i]B-TreeM=41~642 

3、數據庫索引 

1．什麼是索引 

）索引能夠避免全表掃描。多數查詢能夠僅掃描少許索引頁及數據頁，而不是遍歷全部數據頁。

）對於非彙集索引，有些查詢甚至能夠不訪問數據頁。

）彙集索引能夠避免數據插入操做集中於表的最後一個數據頁。

）一些狀況下，索引還可用於避免排序操做。  

2.索引的存儲 

鍵值+（指向數據頁或者另外一索引頁）。

）建立兩個兒子結點

）將原根結點中的數據近似地拆成兩半，分別寫入新的兩個兒子結點

）根結點中加上指向兩個兒子結點的指針 4-9I/O 

3．索引的類型 

）彙集索引，表數據按照索引的順序來存儲的。對於彙集索引，葉子結點即存儲了真實的數據行，再也不有另外單獨的數據頁。

）非彙集索引，表數據存儲順序與索引順序無關。對於非彙集索引，葉結點包含索引字段值及指向數據頁數據行的邏輯指針，該層緊鄰數據頁，其行數量與數據錶行數據量一致。 「」Heap 

4．彙集索引 

 

）彙集索引與查詢操做Green它介於[Bennet,Karsen]1007「Green」[Greane, Hunter]1133 

IO3(Physical Read)(Logical Read)IO 

）彙集索引與插入操做

）在該使用的數據段（）上分配新的數據頁，若是數據段已滿，則須要分配新段。

）調整索引指針，這須要將相應的索引頁讀入內存並加鎖。

）大約有一半的數據行被納入新的數據頁中。

）若是新插入的一條記錄包含很大的數據，可能會分配兩個新數據頁，其中之一用來存儲新記錄，另外一存儲從原頁中拆分出來的數據。

）一般數據庫系統中會將重複的數據記錄存儲於相同的頁中。

）相似於自增列爲彙集索引的，數據庫系統可能並不拆分數據頁，頁只是簡單的新添數據頁。

）彙集索引與刪除操做

5．非彙集索引 

）葉子結點並不是數據結點

）葉子結點爲每一真正的數據行存儲一個鍵指針對

）葉子結點中還存儲了一個指針偏移量，根據頁指針及指針偏移量能夠定位到具體的數據行。

）索引字段值

）（即對應數據頁的頁指針指針偏移量）。在高層的索引頁中包含是爲了當索引容許重複值時，當更改數據時精肯定位數據行。

）下一級索引頁的指針

）索引字段值

）

）非彙集索引與查詢操做

GreenIO3+1IO）非彙集索引與插入操做

）非彙集索引與刪除操做

Where6．索引覆蓋 

31600BelectWhere,Order By,Group By,Having「」匹配索引掃描

非匹配索引掃描

）匹配索引掃描

Where「」Leading ColumnA,B,C,DA「」WhereBCDBD）非配置索引掃描

Where [參考]

http://manuals.sybase.com/onlinebooks/group-asarc/asg1200e/aseperf/@Generic__BookTextView/3358

 

 

 

數據庫索引的實現原理

強烈建議參閱連接：http://www.linezing.com/blog/?p=798#nav-1

 

說白了，索引問題就是一個查找問題。。。

 

數據庫索引，是數據庫管理系統中一個排序的數據結構，以協助快速查詢、更新數據庫表中數據。索引的實現一般使用B樹及其變種B+樹。

在數據以外，數據庫系統還維護着知足特定查找算法的數據結構，這些數據結構以某種方式引用（指向）數據，這樣就能夠在這些數據結構上實現高級查找算法。這種數據結構，就是索引。

爲表設置索引要付出代價的：一是增長了數據庫的存儲空間，二是在插入和修改數據時要花費較多的時間(由於索引也要隨之變更)。

 

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

 

建立索引能夠大大提升系統的性能。

第一，經過建立惟一性索引，能夠保證數據庫表中每一行數據的惟一性。

第二，能夠大大加快數據的檢索速度，這也是建立索引的最主要的緣由。

第三，能夠加速表和表之間的鏈接，特別是在實現數據的參考完整性方面特別有意義。

第四，在使用分組和排序子句進行數據檢索時，一樣能夠顯著減小查詢中分組和排序的時間。

第五，經過使用索引，能夠在查詢的過程當中，使用優化隱藏器，提升系統的性能。 

 

也許會有人要問：增長索引有如此多的優勢，爲何不對錶中的每個列建立一個索引呢？由於，增長索引也有許多不利的方面。

第一，建立索引和維護索引要耗費時間，這種時間隨着數據量的增長而增長。

第二，索引須要佔物理空間，除了數據表佔數據空間以外，每個索引還要佔必定的物理空間，若是要創建聚簇索引，那麼須要的空間就會更大。

第三，當對錶中的數據進行增長、刪除和修改的時候，索引也要動態的維護，這樣就下降了數據的維護速度。

 

索引是創建在數據庫表中的某些列的上面。在建立索引的時候，應該考慮在哪些列上能夠建立索引，在哪些列上不能建立索引。通常來講，應該在這些列上建立索引：在常常須要搜索的列上，能夠加快搜索的速度；在做爲主鍵的列上，強制該列的惟一性和組織表中數據的排列結構；在常常用在鏈接的列上，這些列主要是一些外鍵，能夠加快鏈接的速度；在常常須要根據範圍進行搜索的列上建立索引，由於索引已經排序，其指定的範圍是連續的；在常常須要排序的列上建立索引，由於索引已經排序，這樣查詢能夠利用索引的排序，加快排序查詢時間；在常用在WHERE子句中的列上面建立索引，加快條件的判斷速度。

 

一樣，對於有些列不該該建立索引。通常來講，不該該建立索引的的這些列具備下列特色：

第一，對於那些在查詢中不多使用或者參考的列不該該建立索引。這是由於，既然這些列不多使用到，所以有索引或者無索引，並不能提升查詢速度。相反，因爲增長了索引，反而下降了系統的維護速度和增大了空間需求。

第二，對於那些只有不多數據值的列也不該該增長索引。這是由於，因爲這些列的取值不多，例如人事表的性別列，在查詢的結果中，結果集的數據行佔了表中數據行的很大比例，即須要在表中搜索的數據行的比例很大。增長索引，並不能明顯加快檢索速度。

第三，對於那些定義爲text, image和bit數據類型的列不該該增長索引。這是由於，這些列的數據量要麼至關大，要麼取值不多。

第四，當修改性能遠遠大於檢索性能時，不該該建立索引。這是由於，修改性能和檢索性能是互相矛盾的。當增長索引時，會提升檢索性能，可是會下降修改性能。當減小索引時，會提升修改性能，下降檢索性能。所以，當修改性能遠遠大於檢索性能時，不該該建立索引。

 

根據數據庫的功能，能夠在數據庫設計器中建立三種索引：惟一索引、主鍵索引和彙集索引。

惟一索引 

惟一索引是不容許其中任何兩行具備相同索引值的索引。

當現有數據中存在重複的鍵值時，大多數數據庫不容許將新建立的惟一索引與表一塊兒保存。數據庫還可能防止添加將在表中建立重複鍵值的新數據。例如，若是在employee表中職員的姓(lname)上建立了惟一索引，則任何兩個員工都不能同姓。

主鍵索引

數據庫表常常有一列或列組合，其值惟一標識表中的每一行。該列稱爲表的主鍵。

在數據庫關係圖中爲表定義主鍵將自動建立主鍵索引，主鍵索引是惟一索引的特定類型。該索引要求主鍵中的每一個值都惟一。當在查詢中使用主鍵索引時，它還容許對數據的快速訪問。

彙集索引

在彙集索引中，表中行的物理順序與鍵值的邏輯（索引）順序相同。一個表只能包含一個彙集索引。

若是某索引不是彙集索引，則表中行的物理順序與鍵值的邏輯順序不匹配。與非彙集索引相比，彙集索引一般提供更快的數據訪問速度。

 

 

局部性原理與磁盤預讀

因爲存儲介質的特性，磁盤自己存取就比主存慢不少，再加上機械運動耗費，磁盤的存取速度每每是主存的幾百分分之一，所以爲了提升效率，要儘可能減小磁盤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)。通常實際應用中，出度d是很是大的數字，一般超過100，所以h很是小（一般不超過3）。

而紅黑樹這種結構，h明顯要深的多。因爲邏輯上很近的節點（父子）物理上可能很遠，沒法利用局部性，因此紅黑樹的I/O漸進複雜度也爲O(h)，效率明顯比B-Tree差不少。

 

綜上所述，用B-Tree做爲索引結構效率是很是高的。

 

 

應該花時間學習B-樹和B+樹數據結構

=============================================================================================================

1）B樹

B樹中每一個節點包含了鍵值和鍵值對於的數據對象存放地址指針，因此成功搜索一個對象能夠不用到達樹的葉節點。

成功搜索包括節點內搜索和沿某一路徑的搜索，成功搜索時間取決於關鍵碼所在的層次以及節點內關鍵碼的數量。

在B樹中查找給定關鍵字的方法是：首先把根結點取來，在根結點所包含的關鍵字K1,…,kj查找給定的關鍵字（可用順序查找或二分查找法），若找到等於給定值的關鍵字，則查找成功；不然，必定能夠肯定要查的關鍵字在某個Ki或Ki+1之間，因而取Pi所指的下一層索引節點塊繼續查找，直到找到，或指針Pi爲空時查找失敗。

2）B+樹

B+樹非葉節點中存放的關鍵碼並不指示數據對象的地址指針，非也節點只是索引部分。全部的葉節點在同一層上，包含了所有關鍵碼和相應數據對象的存放地址指針，且葉節點按關鍵碼從小到大順序連接。若是實際數據對象按加入的順序存儲而不是按關鍵碼次數存儲的話，葉節點的索引必須是稠密索引，若實際數據存儲按關鍵碼次序存放的話，葉節點索引時稀疏索引。

B+樹有2個頭指針，一個是樹的根節點，一個是最小關鍵碼的葉節點。

因此 B+樹有兩種搜索方法：

一種是按葉節點本身拉起的鏈表順序搜索。

一種是從根節點開始搜索，和B樹相似，不過若是非葉節點的關鍵碼等於給定值，搜索並不中止，而是繼續沿右指針，一直查到葉節點上的關鍵碼。因此不管搜索是否成功，都將走完樹的全部層。

B+ 樹中，數據對象的插入和刪除僅在葉節點上進行。

這兩種處理索引的數據結構的不一樣之處：

a，B樹中同一鍵值不會出現屢次，而且它有可能出如今葉結點，也有可能出如今非葉結點中。而B+樹的鍵必定會出如今葉結點中，而且有可能在非葉結點中也有可能重複出現，以維持B+樹的平衡。

b，由於B樹鍵位置不定，且在整個樹結構中只出現一次，雖然能夠節省存儲空間，但使得在插入、刪除操做複雜度明顯增長。B+樹相比來講是一種較好的折中。

c，B樹的查詢效率與鍵在樹中的位置有關，最大時間複雜度與B+樹相同(在葉結點的時候)，最小時間複雜度爲1(在根結點的時候)。而B+樹的時候複雜度對某建成的樹是固定的。