淺談資料庫索引的作用及原理，淺談資料庫索引

淺談資料庫索引的作用及原理，淺談資料庫索引

資料庫索引是為了增加查詢速度而對錶欄位附加的一種標識。很多人機械的理解索引的概念，認為增加索引只有好處沒有壞處。其實遠不是那樣的，這裡將其介紹盡量詳細些。

首先明白為什麼索引會增加速度，DB在執行一條Sql語句的時候，預設的方式是根據搜尋條件進行全表掃描，遇到匹配條件的就加入搜尋結果集合。如果我們對某一欄位增加索引，查詢時就會先去索引列表中一次定位到特定值的行數，大大減少遍曆匹配的行數，所以能明顯增加查詢的速度。那麼在任何時候都應該加索引嗎？這裡有幾個反例：1、如果每次都需要取到所有表記錄，無論如何都必須進行全表掃描了，那麼是否加索引也沒有意義了。2、對非唯一的欄位，例如“性別”這種大量重複值的欄位，增加索引也沒有什麼意義。3、對於記錄比較少的表，增加索引不會帶來速度的最佳化反而浪費了儲存空間，因為索引是需要儲存空間的，而且有個致命缺點是對於update/insert/delete的每次執行，欄位的索引都必須重新計算更新。

那麼在什麼時候適合加上索引呢？我們看一個Mysql手冊中舉的例子，這裡有一條sql語句：

SELECT c.companyID, c.companyName FROM Companies c, User u WHERE c.companyID = u.fk_companyID AND c.numEmployees >= 0 AND c.companyName LIKE '%i%' AND u.groupID IN (SELECT g.groupID FROM Groups g WHERE g.groupLabel = 'Executive')

這條語句涉及3個表的聯結，並且包括了許多搜尋條件比如大小比較，Like匹配等。在沒有索引的情況下Mysql需要執行的掃描行數是77721876行。而我們通過在companyID和groupLabel兩個欄位上加上索引之後，掃描的行數只需要134行。在Mysql中可以通過Explain Select來查看掃描次數。可以看出來在這種聯表和複雜搜尋條件的情況下，索引帶來的效能提升遠比它所佔據的磁碟空間要重要得多。

那麼索引是如何?的呢？大多數DB廠商實現索引都是基於一種資料結構——B樹。因為B樹的特點就是適合在磁碟等直接存放裝置上組織動態尋找表。B樹的定義是這樣的：一棵m(m>=3)階的B樹是滿足下列條件的m叉樹：

1、每個結點包括如下範圍(j, p0, k1, p1, k2, p2, ... ki, pi) 其中j是關鍵字個數，p是孩子指標

2、所有葉子結點在同一層上，層數等於樹高h

3、每個非根結點包含的關鍵字個數滿足[m/2-1]<=j<=m-1

4、若樹非空，則根至少有1個關鍵字，若根非葉子，則至少有2棵子樹，至多有m棵子樹

看一個B樹的例子，針對26個英文字母的B樹可以這樣構造：

可以看到在這棵B樹搜尋英文字母複雜度只為o(m)，在資料量比較大的情況下，這樣的結構可以大大增加查詢速度。然而有另外一種資料結構查詢的虛度比B樹更快——散列表。Hash表的定義是這樣的：設所有可能出現的關鍵字集合為u，實際發生儲存的關鍵字記為k，而|k|比|u|小很多。散列方法是通過散列函數h將u映射到表T[0,m-1]的下標上，這樣u中的關鍵字為變數，以h為函數運算結果即為相應結點的儲存地址。從而達到可以在o(1)的時間內完成尋找。

然而散列表有一個缺陷，那就是散列衝突，即兩個關鍵字通過散列Function Compute出了相同的結果。設m和n分別表示散列表的長度和填滿的結點數，n/m為散列表的填裝因子，因子越大，表示散列衝突的機會越大。

因為有這樣的缺陷，所以資料庫不會使用散列表來做為索引的預設實現，Mysql宣稱會根據執行查詢格式嘗試將基於磁碟的B樹索引轉變為和合適的散列索引以追求進一步提高搜尋速度。

總結

本文關於資料庫索引的作用和原理就介紹到這裡，希望對大家有所協助。感興趣的朋友可以參閱：oracle資料庫匯入TXT檔案方法介紹  oracle 資料庫啟動階段分析  oracle 虛擬專用資料庫詳細介紹 等。有什麼問題可以隨時留言，小編會及時回複大家的。感謝朋友們對本站的支援！