• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            牽著老婆滿街逛

            嚴以律己,寬以待人. 三思而后行.
            GMail/GTalk: yanglinbo#google.com;
            MSN/Email: tx7do#yahoo.com.cn;
            QQ: 3 0 3 3 9 6 9 2 0 .

            漫談數據庫索引

            轉載自:http://www.cnblogs.com/KissKnife/archive/2009/03/30/1425534.html


            一、引言

            對數據庫索引的關注從未淡出我的們的討論,那么數據庫索引是什么樣的?聚集索引與非聚集索引有什么不同?希望本文對各位同仁有一定的幫助。有不少存疑的地方,誠心希望各位不吝賜教指正,共同進步。[最近首頁之爭沸沸揚揚,也不知道這個放在這合適么,苦勞?功勞?……]

             

            二、B-Tree

            我們常見的數據庫系統,其索引使用的數據結構多是B-Tree或者B+Tree。例如,MsSql使用的是B+Tree,OracleSysbase使用的是B-Tree。所以在最開始,簡單地介紹一下B-Tree。

            B-Tree不同于Binary Tree(二叉樹,最多有兩個子樹),一棵M階的B-Tree滿足以下條件:
            1)每個結點至多有M個孩子;
            2)除根結點和葉結點外,其它每個結點至少有M/2個孩子;
            3)根結點至少有兩個孩子(除非該樹僅包含一個結點);
            4)所有葉結點在同一層,葉結點不包含任何關鍵字信息;
            5)有K個關鍵字的非葉結點恰好包含K+1個孩子;

            另外,對于一個結點,其內部的關鍵字是從小到大排序的。以下是B-TreeM=4)的樣例:

              

            對于每個結點,主要包含一個關鍵字數組Key[],一個指針數組(指向兒子)Son[]。在B-Tree內,查找的流程是:使用順序查找(數組長度較短時)或折半查找方法查找Key[]數組,若找到關鍵字K,則返回該結點的地址及KKey[]中的位置;否則,可確定K在某個Key[i]Key[i+1]之間,則從Son[i]所指的子結點繼續查找,直到在某結點中查找成功;或直至找到葉結點且葉結點中的查找仍不成功時,查找過程失敗。

            接著,我們使用以下圖片演示如何生成B-TreeM=4,依次插入1~6):
            從圖可見,當我們插入關鍵字4時,由于原結點已經滿了,故進行分裂,基本按一半的原則進行分裂,然后取出中間的關鍵字2,升級(這里是成為根結點)。其它的依類推,就是這樣一個大概的過程。

              

             

            三、數據庫索引

            1.什么是索引

            在數據庫中,索引的含義與日常意義上的“索引”一詞并無多大區別(想想小時候查字典),它是用于提高數據庫表數據訪問速度的數據庫對象。
            A)索引可以避免全表掃描。多數查詢可以僅掃描少量索引頁及數據頁,而不是遍歷所有數據頁。
            B對于非聚集索引,有些查詢甚至可以不訪問數據頁。
            C聚集索引可以避免數據插入操作集中于表的最后一個數據頁。
            D一些情況下,索引還可用于避免排序操作。

            當然,眾所周知,雖然索引可以提高查詢速度,但是它們也會導致數據庫系統更新數據的性能下降,因為大部分數據更新需要同時更新索引。

             

            2.索引的存儲

            一條索引記錄中包含的基本信息包括:鍵值(即你定義索引時指定的所有字段的值)+邏輯指針(指向數據頁或者另一索引頁)。

              

            當你為一張空表創建索引時,數據庫系統將為你分配一個索引頁,該索引頁在你插入數據前一直是空的。此頁此時既是根結點,也是葉結點。每當你往表中插入一行數據,數據庫系統即向此根結點中插入一行索引記錄。當根結點滿時,數據庫系統大抵按以下步驟進行分裂:
            A)創建兩個兒子結點
            B)將原根結點中的數據近似地拆成兩半,分別寫入新的兩個兒子結點
            C)根結點中加上指向兩個兒子結點的指針

            通常狀況下,由于索引記錄僅包含索引字段值(以及4-9字節的指針),索引實體比真實的數據行要小許多,索引頁相較數據頁來說要密集許多。一個索引頁可以存儲數量更多的索引記錄,這意味著在索引中查找時在I/O上占很大的優勢,理解這一點有助于從本質上了解使用索引的優勢。

             

            3.索引的類型

            A聚集索引,表數據按照索引的順序來存儲的。對于聚集索引,葉子結點即存儲了真實的數據行,不再有另外單獨的數據頁。
            B非聚集索引,表數據存儲順序與索引順序無關。對于非聚集索引,葉結點包含索引字段值及指向數據頁數據行的邏輯指針,該層緊鄰數據頁,其行數量與數據表行數據量一致。

            在一張表上只能創建一個聚集索引,因為真實數據的物理順序只可能是一種。如果一張表沒有聚集索引,那么它被稱為堆集Heap)。這樣的表中的數據行沒有特定的順序,所有的新行將被添加的表的末尾位置。

             

            4.聚集索引

            在聚集索引中,葉結點也即數據結點,所有數據行的存儲順序與索引的存儲順序一致。

              

            1)聚集索引與查詢操作

            如上圖,我們在名字字段上建立聚集索引,當需要在根據此字段查找特定的記錄時,數據庫系統會根據特定的系統表查找的此索引的根,然后根據指針查找下一個,直到找到。例如我們要查詢“Green”,由于它介于[Bennet,Karsen],據此我們找到了索引頁1007,在該頁中“Green”介于[Greane, Hunter],據此我們找到葉結點1133(也即數據結點),并最終在此頁中找以了目標數據行。

            此次查詢的IO包括3個索引頁的查詢(其中最后一次實際上是在數據頁中查詢)。這里的查找可能是從磁盤讀取(Physical Read)或是從緩存中讀取(Logical Read),如果此表訪問頻率較高,那么索引樹中較高層的索引很可能在緩存中被找到。所以真正的IO可能小于上面的情況。

             

            2)聚集索引與插入操作

            最簡單的情況下,插入操作根據索引找到對應的數據頁,然后通過挪動已有的記錄為新數據騰出空間,最后插入數據。

            如果數據頁已滿,則需要拆分數據頁(頁拆分是一種耗費資源的操作,一般數據庫系統中會有相應的機制要盡量減少頁拆分的次數,通常是通過為每頁預留空間來實現):
            A在該使用的數據段(extent)上分配新的數據頁,如果數據段已滿,則需要分配新段。
            B調整索引指針,這需要將相應的索引頁讀入內存并加鎖。
            C大約有一半的數據行被歸入新的數據頁中。
            D
            如果表還有非聚集索引,則需要更新這些索引指向新的數據頁。

            特殊情況:
            A如果新插入的一條記錄包含很大的數據,可能會分配兩個新數據頁,其中之一用來存儲新記錄,另一存儲從原頁中拆分出來的數據。
            B通常數據庫系統中會將重復的數據記錄存儲于相同的頁中。
            C類似于自增列為聚集索引的,數據庫系統可能并不拆分數據頁,頁只是簡單的新添數據頁。

             

            3)聚集索引與刪除操作

            刪除行將導致其下方的數據行向上移動以填充刪除記錄造成的空白。

            如果刪除的行是該數據頁中的最后一行,那么該數據頁將被回收,相應的索引頁中的記錄將被刪除。如果回收的數據頁位于跟該表的其它數據頁相同的段上,那么它可能在隨后的時間內被利用。如果該數據頁是該段的唯一一個數據頁,則該段也被回收。

            對于數據的刪除操作,可能導致索引頁中僅有一條記錄,這時,該記錄可能會被移至鄰近的索引頁中,原索引頁將被回收,即所謂的“索引合并”。

             

            5.非聚集索引

            非聚集索引與聚集索引相比:
            A葉子結點并非數據結點
            B葉子結點為每一真正的數據行存儲一個-指針
            C葉子結點中還存儲了一個指針偏移量,根據頁指針及指針偏移量可以定位到具體的數據行。
            D
            類似的,在除葉結點外的其它索引結點,存儲的也是類似的內容,只不過它是指向下一級的索引頁的。

            聚集索引是一種稀疏索引,數據頁上一級的索引頁存儲的是頁指針,而不是行指針。而對于非聚集索引,則是密集索引,在數據頁的上一級索引頁它為每一個數據行存儲一條索引記錄。

            對于根與中間級的索引記錄,它的結構包括:
            A索引字段值
            BRowId(即對應數據頁的頁指針+指針偏移量)。在高層的索引頁中包含RowId是為了當索引允許重復值時,當更改數據時精確定位數據行。
            C下一級索引頁的指針

            對于葉子層的索引對象,它的結構包括:
            A
            索引字段值
            BRowId

              

            1)非聚集索引與查詢操作

            針對上圖,如果我們同樣查找“Green”,那么一次查詢操作將包含以下IO3個索引頁的讀取+1個數據頁的讀取。同樣,由于緩存的關系,真實的IO實際可能要小于上面列出的。

             

            2)非聚集索引與插入操作

            如果一張表包含一個非聚集索引但沒有聚集索引,則新的數據將被插入到最末一個數據頁中,然后非聚集索引將被更新。如果也包含聚集索引,該聚集索引將被用于查找新行將要處于什么位置,隨后,聚集索引、以及非聚集索引將被更新。

             

            3)非聚集索引與刪除操作

            如果在刪除命令的Where子句中包含的列上,建有非聚集索引,那么該非聚集索引將被用于查找數據行的位置,數據刪除之后,位于索引葉子上的對應記錄也將被刪除。如果該表上有其它非聚集索引,則它們葉子結點上的相應數據也要刪除。

            如果刪除的數據是該數所頁中的唯一一條,則該頁也被回收,同時需要更新各個索引樹上的指針。

            由于沒有自動的合并功能,如果應用程序中有頻繁的隨機刪除操作,最后可能導致表包含多個數據頁,但每個頁中只有少量數據。

             

            6.索引覆蓋

            索引覆蓋是這樣一種索引策略:當某一查詢中包含的所需字段皆包含于一個索引中,此時索引將大大提高查詢性能。

            包含多個字段的索引,稱為復合索引。索引最多可以包含31個字段,索引記錄最大長度為600B。如果你在若干個字段上創建了一個復合的非聚集索引,且你的查詢中所需Select字段及Where,Order By,Group By,Having子句中所涉及的字段都包含在索引中,則只搜索索引頁即可滿足查詢,而不需要訪問數據頁。由于非聚集索引的葉結點包含所有數據行中的索引列值,使用這些結點即可返回真正的數據,這種情況稱之為索引覆蓋。

            在索引覆蓋的情況下,包含兩種索引掃描:
            A)匹配索引掃描
            B)非匹配索引掃描

             

            1)匹配索引掃描

            此類索引掃描可以讓我們省去訪問數據頁的步驟,當查詢僅返回一行數據時,性能提高是有限的,但在范圍查詢的情況下,性能提高將隨結果集數量的增長而增長。

            針對此類掃描,索引必須包含查詢中涉及的的所有字段,另外,還需要滿足:Where子句中包含索引中的引導列Leading Column),例如一個復合索引包含A,B,C,D四列,則A引導列。如果Where子句中所包含列是BCD或者BD等情況,則只能使用非匹配索引掃描。

             

            2)非配置索引掃描

            正如上述,如果Where子句中不包含索引的導引列,那么將使用非配置索引掃描。這最終導致掃描索引樹上的所有葉子結點,當然,它的性能通常仍強于掃描所有的數據頁。

             

            [參考]
            [1]http://manuals.sybase.com/onlinebooks/group-asarc/asg1200e/aseperf/@Generic__BookTextView/3358
            [2] 
            http://publib.boulder.ibm.com/infocenter/idshelp/v10/index.jsp?topic=/com.ibm.adref.doc/adref235.htm


            posted on 2011-03-31 16:28 楊粼波 閱讀(744) 評論(0)  編輯 收藏 引用

            伊人久久亚洲综合影院| 久久国产精品成人免费| 久久精品国产亚洲欧美| 久久香蕉超碰97国产精品 | 亚洲国产精品无码久久青草| 日本道色综合久久影院| 国产91久久精品一区二区| 99久久精品免费看国产一区二区三区| 久久久久久国产精品美女| 久久激情五月丁香伊人| 精品国产91久久久久久久a| 精品久久久久久国产免费了| 99久久www免费人成精品| 91精品国产高清久久久久久91| 青青青国产精品国产精品久久久久 | 久久久久久久91精品免费观看 | 久久精品中文字幕大胸| 99久久无色码中文字幕人妻| 精品国产乱码久久久久软件| 无码人妻久久一区二区三区 | 久久99精品久久久久久久不卡| 久久综合88熟人妻| 99精品久久久久久久婷婷| 久久久久人妻一区精品| 色婷婷久久久SWAG精品| 亚洲av日韩精品久久久久久a| 久久精品国产第一区二区三区| 久久精品国产亚洲麻豆| 一本大道久久东京热无码AV | 久久国产乱子伦精品免费强| 久久av免费天堂小草播放| 狠狠色婷婷久久一区二区| 久久99热国产这有精品| 久久亚洲国产精品五月天婷| 色综合久久综合中文综合网| 国内精品久久久久久久影视麻豆| 久久精品人人做人人爽电影| 成人久久精品一区二区三区| 午夜精品久久久久久| 四虎国产精品免费久久久| 久久久久av无码免费网|