閱讀導航

提高性能

索引

??? B-tree 索引

??? Hash 索引

??? 其他類型

指針

索引百利無一害

?

?

索引對于接觸過數據庫的人，都不會很陌生，但是說實話，也不一定很熟悉。先來介紹下索引的優點。

?

提高性能

現在有一個數據庫表[Words]，有[WordID]，[WordPage]，[[WordName]，[WordPronunciation] ，[WordMeaning]，[WordSentence]五個列，假設有上萬條記錄。

現在，使用查詢語句找到“boyce”的詳細信息，使用語句

1: SELECT * FROM [Words] 2: WHERE [WordName] = 'boyce'

?

執行這個語句會發生什么？實際上程序在后臺找一個單詞“boyce”。數據庫可能會查找表的每一行，是否存在一個單詞“boyce”。但是，就算找到了表中一個單詞“boyce”的行，數據庫也不會停止檢索，因為剩下的每一行都有可能是一個單詞“boyce”的行，也就是說，知道所有行都被檢索后，數據庫才會停止檢索并返回查詢結果。其實就是做了一個全表檢索。其實，如果一個表只有一百行甚至幾千行數據，就算全表檢索我們也不會又什么明顯的感覺，但是隨著數據的膨脹變大，幾萬行數據甚至更多時，整表檢索可能就是一件令人恐懼的事情。如果這樣的事情發生了，除了等待令人恐怖的檢索，我們還可以做什么呢！使用肉眼去看，這樣可能不是一個明智的做法，正常人干不出這事。

就像這個小標題一樣，我們可以使用索引提高性能。索引是通過使用指針的指向減少了檢索數據表記錄數量來提高性能的。

?

索引

索引是一個可以存儲數據表列值的數據結構（通常都是R-tree）。索引創建在表中列上面。一個很重要的內容就是索引包含表中的列值，并且這些值被存儲到了數據結構中。簡單易記的一句話，索引就是數據結構。

那么可不可以說，索引就是B-tree呢？并不是這樣的，除了有B-tree索引，還有hash索引、R-tree索引、bitmap索引

B-tree 索引

這是最常用的索引。因為，B-tree的索引在查找、刪除、插入操作時的時間復雜度是對數時間。另外一個重要的原因是，可以把數據存儲在B-tree中。但是，索引使用什么樣的數據結構是由RDBMS（關系型數據庫管理系統）決定的。有時候在創建索引的時候也可以指定索引的數據結構類型。

正因為索引是基于數據結構存儲列值值的，所以檢索這些值得時候會更快。B-tree 索引的數據結構也是一個有序的結構。索引提升性能的主要原因是什么呢？

現在在[WordName] 列上創建B-tree索引，這就意味著，在使用上面的語句

1: SELECT * FROM [Words] 2: WHERE [WordName] = 'boyce'

不會再進行全表的掃描。因為索引是可能是按照[WordName] 的字母進行了排序，這就表明，所有以”b” 開頭單詞的索引是挨著的。更重要的是索引中存儲著指向列值實際數據行的指針。

?

Hash 索引

這是可能被索引使用的另一個數據結構類型。在進行查找操作時，使用hash 索引。的效率很高。因此，當使用一個語句去比較字符串，然后返回結果集，這樣的操作使用hash 索引是很快的。就像前面的語句

1: SELECT * FROM [Words] 2: WHERE [WordName] = 'boyce'

在列[WordName] 上創建hash 索引是一個很好的。這時，列值將插入到hash 表中和一個鍵對應，并和實際的數據行有一個映射關系，也就是該鍵是一個指向表中數據行的指針。hash 表實際是基于關聯數組，假如有這樣一個語句“boyce = 0×28936”，0×28936是關聯到存儲在內存中的boyce。在hash表索引中查找“boyce”的值并返回內存中的數據，要比檢索整個表的[WordName]列值要快得多。

照這樣的說法，是不是以后創建hash 索引好了？

其實不然

hash 表不是一個被排序的數據結構，很多類型的hash索引查詢根本就沒有性能的提升。比如。檢索300頁以內的所有單詞。因為，hash 表擅長的是檢索鍵值對，也就是說，檢索語句檢查相等性（如，“WHERE [WordName] = “boyce” ”）。在hash 表中的鍵值是沒有排序的，在存儲的時候也沒有任何的排序規則。因為hash 索引不夠靈活。所以，hash 索引不是默認索引的數據結構。

是不是，創建所有的索引使用默認的b-tree數據結構就完事大吉了呢？

下面的情況還是最好考慮使用hash 索引：

表中存在字段過長，這樣的列是不適合創建索引的，創建索引的原則是索引不能太寬。

對于varchar(max)、nvarchar(max) 和 varbinary(max)的大值數據類型也不適合創建索引。

其他類型

使用R-tree 數據結構的索引，這個主要是解決一些特定的問題。比如，找到方圓五百米的美女/帥哥，這是使用R-tree 索引，性能會有一定的提升。

還有bitmap 索引，在列值為Boolean值時，該類索引是相當有效的。一般用在選擇性列上。

?

指針

有一個問題：在索引中檢索一個值（比如，boyce），是怎么樣也找到該行其他的列的值呢（[WordID]、[WordPage]……）？

可能會說，So easy！因為存在指針。

是這樣的，還是讓我來啰嗦一下。

索引中存儲指向相應行的指針。這個指針是關聯到一塊內存，該內存中存儲了相應數據在硬盤的地址。也就是說，添加為索引的列值是存儲在索引中，指向相應數據行的指針也是存儲在索引中。這就意味著，[WordName] 在索引中就是像這樣（“boyce”，“0×82937”），那么，0×82937的地址就是“boyce” 所在行在磁盤中的地址。通過這個例子，可以看出， 單值得指針其實沒有用的，是沒有意義的，因為他不能得到相應數據行的值。

?

索引百利無一害

索引創建在表的列上，這個概念大家已經非常清晰了。索引只是存儲了特定的列，并沒有把表中所有的列全部存儲到索引中。例如，在[WordName] 列上創建索引，這就意味著，[WordID]，[WordPage]…… 沒有存儲在索引中。如果創建索引在所有的列上，那就相當于把 整個表復制了一份，這會占據很大的空間并且效率也很低。

現在我們知道，創建索引其實會占據一定空間的，越大的表，創建索引占據的空間越大。還有，在所添加、刪除、和更新行的時候，都需要相應的維護索引，這樣數據庫的性能可能會降低。

一般的規則，被頻繁檢索的列,才在該列創建索引。

轉載于:https://www.cnblogs.com/jameslif/p/3664013.html

總結

以上是生活随笔為你收集整理的[数据库基础]——索引详解的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。