大家好，精選小編來為大家解答以上的問題。數據庫查詢索引的好處和壞處，數據庫索引有什么作用和好處很多人還不知道，現在讓我們一起來看看吧！
數據庫是附加在表字段上的標識，以提高查詢速度。我看到很多人機械地理解指數的概念，認為增加指數只有好處沒有壞處。在這里，我總結一下之前關于索引學習的注意事項：一、我明白為什么索引會提高速度。DB執行一條Sql語句時，默認的方式是根據搜索條件掃描整個表，當滿足匹配條件時加入搜索結果集。如果我們給某個字段添加了索引，那么在查詢時，我們會先去索引列表定位一次有特定值的行數，這樣就大大減少了遍歷匹配的行數，所以可以明顯提高查詢速度。那么是否應該隨時索引呢？下面舉幾個反例：1。如果每次都需要檢索所有的表記錄，而且無論如何都要掃描整個表，那么索引與否就沒有意義了。2.對于非唯一字段，如“性別”，有大量重復值，增加索引沒有意義。3.對于記錄較少的表，增加索引并不會帶來速度優化，反而會浪費存儲空間，因為索引需要存儲空間。此外，還有一個致命的缺點，即每次執行更新/插入/刪除時，必須重新計算和更新字段的索引。那么什么時候是添加索引的合適時機呢？讓我們看一個Mysql手冊中的例子。下面是一個sql語句：select c.companyid，c.company name from companies c，User u其中c.companyID=u.fk_companyID和c.numEmployees=0和c.companyName LIKE '%i% '和u . groupid IN(SELECT g . groupid FROM Groups g其中g . groupLabel='Executive ')這個語句涉及到三個表的連接，并且包括許多搜索條件，比如大小比較、LIKE匹配等。Mysql在沒有索引的情況下需要執行的掃描行數是77721876。但是，在companyID和groupLabel字段中添加索引后，掃描的行數只需要134。在Mysql中，你可以通過解釋選擇來檢查掃描時間。可以看出，在這種表連接和復雜搜索條件的情況下，索引帶來的性能提升遠比它占用的磁盤空間重要。那么索引是如何實現的呢？大多數數據庫供應商基于數據結構——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。如果樹不為空，則根至少有一個關鍵字；如果根不是葉子，那么至少有兩個子樹，最多有m個子樹。以B樹為例，一棵26個英文字母的B樹可以這樣構造：可以看出，在這棵B樹中搜索英文字母的復雜度只有o .然而，還有一種數據結構，比B樹更快。哈希表的定義如下：設所有可能的關鍵字集合為U，實際存儲的關鍵字為K，且|k|遠小于|u|。哈希方法是通過哈希函數H將U映射到表T[0，m-1]的下標，這樣U中的關鍵字就是一個變量，以H為函數的運算結果就是對應節點的存儲地址。這樣搜索可以在o(1)時間內完成。但是哈希表有一個缺陷，就是哈希沖突，也就是兩個關鍵詞有相同的哈希函數計算結果。設m和n分別代表哈希表的長度和填充的節點數，n/m是哈希表的填充因子。因子越大，哈希沖突的幾率就越大。由于這個缺陷，數據庫不會使用哈希表作為索引的默認實現。Mysql聲稱，為了進一步提高搜索速度，它將嘗試根據查詢格式將基于磁盤的B樹索引轉換為合適的哈希索引。
我認為其他數據庫廠商也會有類似的策略。畢竟在數據庫戰場，搜索速度和管理安全一樣重要。
本文到此結束，希望對大家有所幫助。
