關於數據庫索引，必須掌握的知識點

MySQL的索引是數據庫很是重要的知識點，這些知識點你都掌握了嗎？若是有幫到你能夠點贊收藏呦。

推薦閱讀：這些必會的計算機網絡知識點你都掌握了嗎

目錄

• 什麼是索引？
• 索引的優缺點？
• 索引的數據結構？
• Hash索引和B+樹的區別？
• 索引的類型有哪些?
• 索引的種類有哪些？
• B樹和B+樹的區別？
• 數據庫爲何使用B+樹而不是B樹？
• 什麼是聚簇索引，什麼是非聚簇索引？
• 非聚簇索引必定會進行回表查詢嗎？
• 索引的使用場景有哪些？
• 索引的設計原則？
• 如何對索引進行優化？
• 如何建立/刪除索引？
• 使用索引查詢時性能必定會提高嗎？
• 什麼是前綴索引？
• 什麼是最左匹配原則？
• 索引在什麼狀況下會失效？

什麼是索引？

百度百科的解釋：索引是對數據庫表的一列或者多列的值進行排序一種結構，使用索引能夠快速訪問數據表中的特定信息。

索引的優缺點？

優勢：

• 大大加快數據檢索的速度。
• 將隨機I/O變成順序I/O(由於B+樹的葉子節點是鏈接在一塊兒的)
• 加速表與表之間的鏈接

缺點：

• 從空間角度考慮，創建索引須要佔用物理空間
• 從時間角度 考慮，建立和維護索引都須要花費時間，例如對數據進行增刪改的時候都須要維護索引。

索引的數據結構？

索引的數據結構主要有B+樹和哈希表，對應的索引分別爲B+樹索引和哈希索引。InnoDB引擎的索引類型有B+樹索引和哈希索引，默認的索引類型爲B+樹索引。

• B+樹索引

  熟悉數據結構的同窗都知道，B+樹、平衡二叉樹、紅黑樹都是經典的數據結構。在B+樹中，全部的記錄節點都是按照鍵值大小的順序放在葉子節點上，以下圖。

從上圖能夠看出 ，由於B+樹具備有序性，而且全部的數據都存放在葉子節點，因此查找的效率很是高，而且支持排序和範圍查找。

B+樹的索引又能夠分爲主索引和輔助索引。其中主索引爲聚簇索引，輔助索引爲非聚簇索引。聚簇索引是以主鍵做爲B+ 樹索引的鍵值所構成的B+樹索引，聚簇索引的葉子節點存儲着完整的數據記錄；非聚簇索引是以非主鍵的列做爲B+樹索引的鍵值所構成的B+樹索引，非聚簇索引的葉子節點存儲着主鍵值。因此使用非聚簇索引進行查詢時，會先找到主鍵值，而後到根據聚簇索引找到主鍵對應的數據域。上圖中葉子節點存儲的是數據記錄，爲聚簇索引的結構圖，非聚簇索引的結構圖以下：

上圖中的字母爲數據的非主鍵的列值，假設要查詢該列值爲B的信息，則需先找到主鍵7，在到聚簇索引中查詢主鍵7所對應的數據域。

• 哈希索引

  哈希索引是基於哈希表實現的，對於每一行數據，存儲引擎會對索引列經過哈希算法進行哈希計算獲得哈希碼，而且哈希算法要儘可能保證不一樣的列值計算出的哈希碼值是不一樣的，將哈希碼的值做爲哈希表的key值，將指向數據行的指針做爲哈希表的value值。這樣查找一個數據的時間複雜度就是o(1)，通常多用於精確查找。

Hash索引和B+樹的區別？

由於二者數據結構上的差別致使它們的使用場景也不一樣，哈希索引通常多用於精確的等值查找，B+索引則多用於除了精確的等值查找外的其餘查找。在大多數狀況下，會選擇使用B+樹索引。

• 哈希索引不支持排序，由於哈希表是無序的。
• 哈希索引不支持範圍查找。
• 哈希索引不支持模糊查詢及多列索引的最左前綴匹配。
• 由於哈希表中會存在哈希衝突，因此哈希索引的性能是不穩定的，而B+樹索引的性能是相對穩定的，每次查詢都是從根節點到葉子節點

索引的類型有哪些?

MySQL主要的索引類型主要有FULLTEXT，HASH，BTREE，RTREE。

• FULLTEXT

  FULLTEXT即全文索引，MyISAM存儲引擎和InnoDB存儲引擎在MySQL5.6.4以上版本支持全文索引，通常用於查找文本中的關鍵字，而不是直接比較是否相等，多在CHAR，VARCHAR，TAXT等數據類型上建立全文索引。全文索引主要是用來解決WHERE name LIKE "%zhang%"等針對文本的模糊查詢效率低的問題。

• HASH

  HASH即哈希索引，哈希索引多用於等值查詢，時間複雜夫爲o(1)，效率很是高，但不支持排序、範圍查詢及模糊查詢等。

• BTREE

  BTREE即B+樹索引，INnoDB存儲引擎默認的索引，支持排序、分組、範圍查詢、模糊查詢等，而且性能穩定。

• RTREE

  RTREE即空間數據索引，多用於地理數據的存儲，相比於其餘索引，空間數據索引的優點在於範圍查找

索引的種類有哪些？

• 主鍵索引：數據列不容許重複，不能爲NULL，一個表只能有一個主鍵索引
• 組合索引：由多個列值組成的索引。
• 惟一索引：數據列不容許重複，能夠爲NULL，索引列的值必須惟一的，若是是組合索引，則列值的組合必須惟一。
• 全文索引：對文本的內容進行搜索。
• 普通索引：基本的索引類型，能夠爲NULL

B樹和B+樹的區別？

B樹和B+樹最主要的區別主要有兩點：

• B樹中的內部節點和葉子節點均存放鍵和值，而B+樹的內部節點只有鍵沒有值，葉子節點存放全部的鍵和值。

• B＋樹的葉子節點是經過相連在一塊兒的，方便順序檢索。

  二者的結構圖以下。

數據庫爲何使用B+樹而不是B樹？

• B樹適用於隨機檢索，而B+樹適用於隨機檢索和順序檢索
• B+樹的空間利用率更高，由於B樹每一個節點要存儲鍵和值，而B+樹的內部節點只存儲鍵，這樣B+樹的一個節點就能夠存儲更多的索引，從而使樹的高度變低，減小了I/O次數，使得數據檢索速度更快。
• B+樹的葉子節點都是鏈接在一塊兒的，因此範圍查找，順序查找更加方便
• B+樹的性能更加穩定，由於在B+樹中，每次查詢都是從根節點到葉子節點，而在B樹中，要查詢的值可能不在葉子節點，在內部節點就已經找到。

那在什麼狀況適合使用B樹呢，由於B樹的內部節點也能夠存儲值，因此能夠把一些頻繁訪問的值放在距離根節點比較近的地方，這樣就能夠提升查詢效率。綜上所述，B+樹的性能更加適合做爲數據庫的索引。

什麼是聚簇索引，什麼是非聚簇索引？

聚簇索引和非聚簇索引最主要的區別是數據和索引是否分開存儲。

• 聚簇索引：將數據和索引放到一塊兒存儲，索引結構的葉子節點保留了數據行。
• 非聚簇索引：將數據進和索引分開存儲，索引葉子節點存儲的是指向數據行的地址。

在InnoDB存儲引擎中，默認的索引爲B+樹索引，利用主鍵建立的索引爲主索引，也是聚簇索引，在主索引之上建立的索引爲輔助索引，也是非聚簇索引。爲何說輔助索引是在主索引之上建立的呢，由於輔助索引中的葉子節點存儲的是主鍵。

在MyISAM存儲引擎中，默認的索引也是B+樹索引，但主索引和輔助索引都是非聚簇索引，也就是說索引結構的葉子節點存儲的都是一個指向數據行的地址。而且使用輔助索引檢索無需訪問主鍵的索引。

能夠從很是經典的兩張圖看看它們的區別(圖片來源於網絡)：

非聚簇索引必定會進行回表查詢嗎？

上面是說了非聚簇索引的葉子節點存儲的是主鍵，也就是說要先經過非聚簇索引找到主鍵，再經過聚簇索引找到主鍵所對應的數據，後面這個再經過聚簇索引找到主鍵對應的數據的過程就是回表查詢，那麼非聚簇索引就必定會進行回表查詢嗎？

答案是不必定的，這裏涉及到一個索引覆蓋的問題，若是查詢的數據再輔助索引上徹底能獲取到便不須要回表查詢。例若有一張表存儲着我的信息包括id、name、age等字段。假設聚簇索引是以ID爲鍵值構建的索引，非聚簇索引是以name爲鍵值構建的索引，select id,name from user where name = 'zhangsan';這個查詢便不須要進行回表查詢由於，經過非聚簇索引已經能所有檢索出數據，這就是索引覆蓋的狀況。若是查詢語句是這樣，select id,name,age from user where name = 'zhangsan';則須要進行回表查詢，由於經過非聚簇索引不能檢索出age的值。那應該如何解決那呢？只須要將索引覆蓋便可，創建age和name的聯合索引再使用select id,name,age from user where name = 'zhangsan';進行查詢便可。

因此經過索引覆蓋能解決非聚簇索引回表查詢的問題。

索引的使用場景有哪些？

• 對於中大型表創建索引很是有效，對於很是小的表，通常所有表掃描速度更快些。
• 對於超大型的表，創建和維護索引的代價也會變高，這時能夠考慮分區技術。
• 如何表的增刪改很是多，而查詢需求很是少的話，那就沒有必要創建索引了，由於維護索引也是須要代價的。
• 通常不會出現再where條件中的字段就沒有必要創建索引了。
• 多個字段常常被查詢的話能夠考慮聯合索引。
• 字段多且字段值沒有重複的時候考慮惟一索引。
• 字段多且有重複的時候考慮普通索引。

索引的設計原則？

• 最適合索引的列是在where後面出現的列或者鏈接句子中指定的列，而不是出如今SELECT關鍵字後面的選擇列表中的列。
• 索引列的基數越大，索引的效果越好，換句話說就是索引列的區分度越高，索引的效果越好。好比使用性別這種區分度很低的列做爲索引，效果就會不好，由於列的基數最多也就是三種，大多不是男性就是女性。
• 儘可能使用短索引，對於較長的字符串進行索引時應該指定一個較短的前綴長度，由於較小的索引涉及到的磁盤I/O較少，而且索引高速緩存中的塊能夠容納更多的鍵值，會使得查詢速度更快。
• 儘可能利用最左前綴。
• 不要過分索引，每一個索引都須要額外的物理空間，維護也須要花費時間，因此索引不是越多越好。

如何對索引進行優化？

對索引的優化其實最關鍵的就是要符合索引的設計原則和應用場景，將不符合要求的索引優化成符合索引設計原則和應用場景的索引。

除了索引的設計原則和應用場景那幾點外，還能夠從如下兩方面考慮。

• 在進行查詢時，索引列不能是表達式的一部分，也不能是函數的參數，由於這樣沒法使用索引。例如select * from table_name where a + 1 = 2
• 將區分度最高的索引放在前面
• 儘可能少使用select*

索引的使用場景、索引的設計原則和如何對索引進行優化能夠當作一個問題。

如何建立/刪除索引？

建立索引：

• 使用CREATE INDEX 語句

  CREATE INDEX index_name ON table_name (column_list);

• 在CREATE TABLE時建立

  CREATE TABLE user(
  	id INT PRIMARY KEY,
  	information text,
  	FULLTEXT KEY (information)
  );

• 使用ALTER TABLE建立索引

  ALTER TABLE table_name ADD INDEX index_name (column_list);

刪除索引：

• 刪除主鍵索引

  alter table 表名 drop primary key

• 刪除其餘索引

  alter table 表名 drop key 索引名

使用索引查詢時性能必定會提高嗎？

不必定，前面在索引的使用場景和索引的設計原則中已經提到了如何合理地使用索引，由於建立和維護索引須要花費空間和時間上的代價，若是不合理地使用索引反而會使查詢性能降低。

什麼是前綴索引？

前綴索引是指對文本或者字符串的前幾個字符創建索引，這樣索引的長度更短，查詢速度更快。

使用場景：前綴的區分度比較高的狀況下。

創建前綴索引的方式

ALTER TABLE table_name ADD KEY(column_name(prefix_length));

這裏面有個prefix_length參數很難肯定，這個參數就是前綴長度的意思。一般可使用如下方法進行肯定，先計算全列的區分度

SELECT COUNT(DISTINCT column_name) / COUNT(*) FROM table_name;

而後在計算前綴長度爲多少時和全列的區分度最類似。

SELECT COUNT(DISTINCT LEFT(column_name, prefix_length)) / COUNT(*) FROM table_name;

不斷地調整prefix_length的值，直到和全列計算出區分度相近。

什麼是最左匹配原則？

最左匹配原則：從最左邊爲起點開始連續匹配，遇到範圍查詢（<、>、between、like）會中止匹配。

例如創建索引(a,b,c)，你們能夠猜想如下幾種狀況是否用到了索引。

• 第一種

  select * from table_name where a = 1 and b = 2 and c = 3 
  select * from table_name where b = 2 and a = 1 and c = 3

  上面兩次查詢過程當中全部值都用到了索引，where後面字段調換不會影響查詢結果，由於MySQL中的優化器會自動優化查詢順序。

• 第二種

  select * from table_name where a = 1
  select * from table_name where a = 1 and b = 2  
  select * from table_name where a = 1 and b = 2 and c = 3

  答案是三個查詢語句都用到了索引，由於三個語句都是從最左開始匹配的。

• 第三種

  select * from table_name where  b = 1 
  select * from table_name where  b = 1 and c = 2

  答案是這兩個查詢語句都沒有用到索引，由於不是從最左邊開始匹配的

• 第四種

  select * from table_name where a = 1 and c = 2

  這個查詢語句只有a列用到了索引，c列沒有用到索引，由於中間跳過了b列，不是從最左開始連續匹配的。

• 第五種

  select * from table_name where  a = 1 and b < 3 and c < 1

  這個查詢中只有a列和b列使用到了索引，而c列沒有使用索引，由於根據最左匹配查詢原則，遇到範圍查詢會中止。

• 第六種

  select * from table_name where a like 'ab%'; 
  select * from table_name where  a like '%ab'
  select * from table_name where  a like '%ab%'

  對於列爲字符串的狀況，只有前綴匹配可使用索引，中綴匹配和後綴匹配只能進行全表掃描。

索引在什麼狀況下會失效？

在上面介紹了幾種不符合最左匹配原則的狀況會致使索引失效，除此以外，如下這幾種狀況也會致使索引失效。

• 條件中有or，例如select * from table_name where a = 1 or b = 3
• 在索引上進行計算會致使索引失效，例如select * from table_name where a + 1 = 2
• 在索引的類型上進行數據類型的隱形轉換，會致使索引失效，例如字符串必定要加引號，假設 select * from table_name where a = '1' 會使用到索引，若是寫成select * from table_name where a = 1 則會致使索引失效。
• 在索引中使用函數會致使索引失效，例如select * from table_name where abs(a) = 1
• 在使用like查詢時以%開頭會致使索引失效
• 索引上使用！、=、<>進行判斷時會致使索引失效，例如select * from table_name where a != 1
• 索引字段上使用 is null/is not null判斷時會致使索引失效，例如select * from table_name where a is null