24個經典的MySQL索引問題,你都遇到過哪些?

索引

1、什麼是索引?

2、索引有哪些優缺點?

3、索引使用場景(重點)

4、索引有哪幾種類型?

5、索引的數據結構(b樹,hash)

6、索引的基本原理

7、索引算法有哪些?

8、索引設計的原則?

9、創建索引的原則(重中之重)

10、創建索引的三種方式,刪除索引

11、創建索引時需要注意什麼?

12、使用索引查詢一定能提高查詢的性能嗎?爲什麼

13、百萬級別或以上的數據如何刪除

14、前綴索引

15、什麼是最左前綴原則?什麼是最左匹配原則

16、B樹和B+樹的區別

17、使用B樹的好處

18、使用B+樹的好處

19、Hash索引和B+樹所有有什麼區別或者說優劣呢?

20、數據庫爲什麼使用B+樹而不是B樹

21、B+樹在滿足聚簇索引和覆蓋索引的時候不需要回表查詢數據,

22、什麼是聚簇索引?何時使用聚簇索引與非聚簇索引

23、非聚簇索引一定會回表查詢嗎?

24、聯合索引是什麼?爲什麼需要注意聯合索引中的順序?

1、什麼是索引?

索引是一種特殊的文件(InnoDB數據表上的索引是表空間的一個組成部分),它們包含着對數據表裏所有記錄的引用指針。

索引是一種數據結構。數據庫索引,是數據庫管理系統中一個排序的數據結構,以協助快速查詢、更新數據庫表中數據。索引的實現通常使用B樹及其變種B+樹。

更通俗的說,索引就相當於目錄。爲了方便查找書中的內容,通過對內容建立索引形成目錄。索引是一個文件,它是要佔據物理空間的。

2、索引有哪些優缺點?

索引的優點

(1)可以大大加快數據的檢索速度,這也是創建索引的最主要的原因。

(2)通過使用索引,可以在查詢的過程中,使用優化隱藏器,提高系統的性能。

索引的缺點

(1)時間方面:創建索引和維護索引要耗費時間,具體地,當對錶中的數據進行增加、刪除和修改的時候,索引也要動態的維護,會降低增/改/刪的執行效率;

(2)空間方面:索引需要佔物理空間。

3、索引使用場景(重點)

where

上圖中,根據id查詢記錄,因爲id字段僅建立了主鍵索引,因此此SQL執行可選的索引只有主鍵索引,如果有多個,最終會選一個較優的作爲檢索的依據。

-- 增加一個沒有建立索引的字段altertable innodb1 add sex char(1);
-- 按sex檢索時可選的索引爲nullEXPLAINSELECT*from innodb1 where sex='男';

可以嘗試在一個字段未建立索引時,根據該字段查詢的效率,然後對該字段建立索引(alter table 表名 add index(字段名)),同樣的SQL執行的效率,你會發現查詢效率會有明顯的提升(數據量越大越明顯)。

order by

當我們使用order by將查詢結果按照某個字段排序時,如果該字段沒有建立索引,那麼執行計劃會將查詢出的所有數據使用外部排序(將數據從硬盤分批讀取到內存使用內部排序,最後合併排序結果),這個操作是很影響性能的,因爲需要將查詢涉及到的所有數據從磁盤中讀到內存(如果單條數據過大或者數據量過多都會降低效率),更無論讀到內存之後的排序了。

但是如果我們對該字段建立索引alter table 表名 add index(字段名),那麼由於索引本身是有序的,因此直接按照索引的順序和映射關係逐條取出數據即可。而且如果分頁的,那麼只用取出索引表某個範圍內的索引對應的數據,而不用像上述那取出所有數據進行排序再返回某個範圍內的數據。(從磁盤取數據是最影響性能的)

join

對join語句匹配關係(on)涉及的字段建立索引能夠提高效率

索引覆蓋

如果要查詢的字段都建立過索引,那麼引擎會直接在索引表中查詢而不會訪問原始數據(否則只要有一個字段沒有建立索引就會做全表掃描),這叫索引覆蓋。因此我們需要儘可能的在select後只寫必要的查詢字段,以增加索引覆蓋的機率。

這裏值得注意的是不要想着爲每個字段建立索引,因爲優先使用索引的優勢就在於其體積小。

4、索引有哪幾種類型?

主鍵索引: 

數據列不允許重複,不允許爲NULL,一個表只能有一個主鍵。

唯一索引: 

數據列不允許重複,允許爲NULL值,一個表允許多個列創建唯一索引。

(1)可以通過 ALTER TABLE table_name ADD UNIQUE (column); 創建唯一索引

(2)可以通過 ALTER TABLE table_name ADD UNIQUE (column1,column2);創建唯一組合索引

普通索引: 

基本的索引類型,沒有唯一性的限制,允許爲NULL值。

(1)可以通過ALTER TABLE table_name ADD INDEX index_name (column);創建普通索引

(2)可以通過ALTER TABLE table_name ADD INDEX index_name(column1, column2, column3);創建組合索引

全文索引: 

是目前搜索引擎使用的一種關鍵技術。

可以通過ALTER TABLE table_name ADD FULLTEXT (column);創建全文索引

5、索引的數據結構(b樹,hash)

索引的數據結構和具體存儲引擎的實現有關,在MySQL中使用較多的索引有Hash索引B+樹索引等,而我們經常使用的InnoDB存儲引擎的默認索引實現爲:B+樹索引。對於哈希索引來說,底層的數據結構就是哈希表,因此在絕大多數需求爲單條記錄查詢的時候,可以選擇哈希索引,查詢性能最快;其餘大部分場景,建議選擇BTree索引。

(1)B樹索引

mysql通過存儲引擎取數據,基本上90%的人用的就是InnoDB了,按照實現方式分,InnoDB的索引類型目前只有兩種:BTREE(B樹)索引和HASH索引。B樹索引是Mysql數據庫中使用最頻繁的索引類型,基本所有存儲引擎都支持BTree索引。通常我們說的索引不出意外指的就是(B樹)索引(實際是用B+樹實現的,因爲在查看錶索引時,mysql一律打印BTREE,所以簡稱爲B樹索引)

查詢方式:

主鍵索引區:PI(關聯保存的時數據的地址)按主鍵查詢,

普通索引區:si(關聯的id的地址,然後再到達上面的地址)。所以按主鍵查詢,速度最快

B+tree性質:

1)n棵子tree的節點包含n個關鍵字,不用來保存數據而是保存數據的索引。

2)所有的葉子結點中包含了全部關鍵字的信息,及指向含這些關鍵字記錄的指針,且葉子結點本身依關鍵字的大小自小而大順序鏈接。

3)所有的非終端結點可以看成是索引部分,結點中僅含其子樹中的最大(或最小)關鍵字。

4)B+ 樹中,數據對象的插入和刪除僅在葉節點上進行。

5)B+樹有2個頭指針,一個是樹的根節點,一個是最小關鍵碼的葉節點。

(2)哈希索引

簡要說下,類似於數據結構中簡單實現的HASH表(散列表)一樣,當我們在mysql中用哈希索引時,主要就是通過Hash算法(常見的Hash算法有直接定址法、平方取中法、摺疊法、除數取餘法、隨機數法),將數據庫字段數據轉換成定長的Hash值,與這條數據的行指針一併存入Hash表的對應位置;如果發生Hash碰撞(兩個不同關鍵字的Hash值相同),則在對應Hash鍵下以鏈表形式存儲。當然這只是簡略模擬圖。

6、索引的基本原理

索引用來快速地尋找那些具有特定值的記錄。如果沒有索引,一般來說執行查詢時遍歷整張表。

索引的原理很簡單,就是把無序的數據變成有序的查詢

(1)把創建了索引的列的內容進行排序

(2)對排序結果生成倒排表

(3)在倒排表內容上拼上數據地址鏈

(4)在查詢的時候,先拿到倒排表內容,再取出數據地址鏈,從而拿到具體數據

7、索引算法有哪些?

索引算法有 BTree算法和Hash算法

BTree算法

BTree是最常用的mysql數據庫索引算法,也是mysql默認的算法。因爲它不僅可以被用在=,>,>=,<,<=和between這些比較操作符上,而且還可以用於like操作符,只要它的查詢條件是一個不以通配符開頭的常量, 例如:

-- 只要它的查詢條件是一個不以通配符開頭的常量select*fromuserwhere name like'jack%';
-- 如果一通配符開頭,或者沒有使用常量,則不會使用索引,例如: select*fromuserwhere name like'%jack';

Hash算法

Hash Hash索引只能用於對等比較,例如=,<=>(相當於=)操作符。由於是一次定位數據,不像BTree索引需要從根節點到枝節點,最後才能訪問到頁節點這樣多次IO訪問,所以檢索效率遠高於BTree索引。

8、索引設計的原則?

(1)適合索引的列是出現在where子句中的列,或者連接子句中指定的列

(2)基數較小的類,索引效果較差,沒有必要在此列建立索引

(3)使用短索引,如果對長字符串列進行索引,應該指定一個前綴長度,這樣能夠節省大量索引空間

(4)不要過度索引。索引需要額外的磁盤空間,並降低寫操作的性能。在修改表內容的時候,索引會進行更新甚至重構,索引列越多,這個時間就會越長。所以只保持需要的索引有利於查詢即可。

9、創建索引的原則(重中之重)

索引雖好,但也不是無限制的使用,最好符合一下幾個原則

1) 最左前綴匹配原則,組合索引非常重要的原則,mysql會一直向右匹配直到遇到範圍查詢(>、<、between、like)就停止匹配,比如a = 1 and b = 2 and c > 3 and d = 4 如果建立(a,b,c,d)順序的索引,d是用不到索引的,如果建立(a,b,d,c)的索引則都可以用到,a,b,d的順序可以任意調整。

2)較頻繁作爲查詢條件的字段纔去創建索引

3)更新頻繁字段不適合創建索引

4)若是不能有效區分數據的列不適合做索引列(如性別,男女未知,最多也就三種,區分度實在太低)

5)儘量的擴展索引,不要新建索引。比如表中已經有a的索引,現在要加(a,b)的索引,那麼只需要修改原來的索引即可。

6)定義有外鍵的數據列一定要建立索引。

7)對於那些查詢中很少涉及的列,重複值比較多的列不要建立索引。

8)對於定義爲text、image和bit的數據類型的列不要建立索引。

10、創建索引的三種方式,刪除索引

第一種方式:在執行CREATE TABLE時創建索引

CREATETABLE user_index2 (

第二種方式:使用ALTER TABLE命令去增加索引

ALTERTABLE table_name ADDINDEX index_name (column_list);

ALTER TABLE用來創建普通索引、UNIQUE索引或PRIMARY KEY索引。

其中table_name是要增加索引的表名,column_list指出對哪些列進行索引,多列時各列之間用逗號分隔。

索引名index_name可自己命名,缺省時,MySQL將根據第一個索引列賦一個名稱。另外,ALTER TABLE允許在單個語句中更改多個表,因此可以在同時創建多個索引。

第三種方式:使用CREATE INDEX命令創建

CREATEINDEX index_name ON table_name (column_list);

CREATE INDEX可對錶增加普通索引或UNIQUE索引。(但是,不能創建PRIMARY KEY索引)

刪除索引

根據索引名刪除普通索引、唯一索引、全文索引:

ALTER TABLE 表名 DROP KEY 索引名 altertable user_index dropKEY NAME;
altertable user_index dropKEY id_card;
altertable user_index dropKEY information;

刪除主鍵索引:alter table 表名 drop primary key(因爲主鍵只有一個)。這裏值得注意的是,如果主鍵自增長,那麼不能直接執行此操作(自增長依賴於主鍵索引):

需要取消自增長再行刪除:

altertable user_index -- 重新定義字段MODIFY id int,dropPRIMARYKEY

但通常不會刪除主鍵,因爲設計主鍵一定與業務邏輯無關。

11、創建索引時需要注意什麼?

(1)非空字段:

應該指定列爲NOT NULL,除非你想存儲NULL。在mysql中,含有空值的列很難進行查詢優化,因爲它們使得索引、索引的統計信息以及比較運算更加複雜。你應該用0、一個特殊的值或者一個空串代替空值;

(2)取值離散大的字段:

(變量各個取值之間的差異程度)的列放到聯合索引的前面,可以通過count()函數查看字段的差異值,返回值越大說明字段的唯一值越多字段的離散程度高;

(3)索引字段越小越好:

數據庫的數據存儲以頁爲單位一頁存儲的數據越多一次IO操作獲取的數據越大效率越高。

12、使用索引查詢一定能提高查詢的性能嗎?爲什麼

通常,通過索引查詢數據比全表掃描要快。但是我們也必須注意到它的代價。

(1)索引需要空間來存儲,也需要定期維護, 每當有記錄在表中增減或索引列被修改時,索引本身也會被修改。 這意味着每條記錄的INSERT,DELETE,UPDATE將爲此多付出4,5 次的磁盤I/O。 因爲索引需要額外的存儲空間和處理,那些不必要的索引反而會使查詢反應時間變慢。使用索引查詢不一定能提高查詢性能,索引範圍查詢(INDEX RANGE SCAN)適用於兩種情況:

(2)基於一個範圍的檢索,一般查詢返回結果集小於表中記錄數的30%

(3)基於非唯一性索引的檢索

13、百萬級別或以上的數據如何刪除

關於索引:由於索引需要額外的維護成本,因爲索引文件是單獨存在的文件,所以當我們對數據的增加,修改,刪除,都會產生額外的對索引文件的操作,這些操作需要消耗額外的IO,會降低增/改/刪的執行效率。所以,在我們刪除數據庫百萬級別數據的時候,查詢MySQL官方手冊得知刪除數據的速度和創建的索引數量是成正比的。

(1)所以我們想要刪除百萬數據的時候可以先刪除索引(此時大概耗時三分多鐘)

(2)然後刪除其中無用數據(此過程需要不到兩分鐘)

(3)刪除完成後重新創建索引(此時數據較少了)創建索引也非常快,約十分鐘左右。

(4)與之前的直接刪除絕對是要快速很多,更別說萬一刪除中斷,一切刪除會回滾。那更是坑了。

14、前綴索引

語法:index(field(10)),使用字段值的前10個字符建立索引,默認是使用字段的全部內容建立索引。

前提:前綴的標識度高。比如密碼就適合建立前綴索引,因爲密碼幾乎各不相同。

實操的難度:在於前綴截取的長度。

我們可以利用select count(*)/count(distinct left(password,prefixLen));,通過從調整prefixLen的值(從1自增)查看不同前綴長度的一個平均匹配度,接近1時就可以了(表示一個密碼的前prefixLen個字符幾乎能確定唯一一條記錄)

15、什麼是最左前綴原則?什麼是最左匹配原則

(1)顧名思義,就是最左優先,在創建多列索引時,要根據業務需求,where子句中使用最頻繁的一列放在最左邊。

(2)最左前綴匹配原則,非常重要的原則,mysql會一直向右匹配直到遇到範圍查詢(>、<、between、like)就停止匹配,比如a = 1 and b = 2 and c > 3 and d = 4 如果建立(a,b,c,d)順序的索引,d是用不到索引的,如果建立(a,b,d,c)的索引則都可以用到,a,b,d的順序可以任意調整。

(3)=和in可以亂序,比如a = 1 and b = 2 and c = 3 建立(a,b,c)索引可以任意順序,mysql的查詢優化器會幫你優化成索引可以識別的形式

16、B樹和B+樹的區別

(1)在B樹中,你可以將鍵和值存放在內部節點和葉子節點;但在B+樹中,內部節點都是鍵,沒有值,葉子節點同時存放鍵和值。

(2)B+樹的葉子節點有一條鏈相連,而B樹的葉子節點各自獨立。

17、使用B樹的好處

B樹可以在內部節點同時存儲鍵和值,因此,把頻繁訪問的數據放在靠近根節點的地方將會大大提高熱點數據的查詢效率。這種特性使得B樹在特定數據重複多次查詢的場景中更加高效。

18、使用B+樹的好處

由於B+樹的內部節點只存放鍵,不存放值,因此,一次讀取,可以在內存頁中獲取更多的鍵,有利於更快地縮小查找範圍。 B+樹的葉節點由一條鏈相連,因此,當需要進行一次全數據遍歷的時候,B+樹只需要使用O(logN)時間找到最小的一個節點,然後通過鏈進行O(N)的順序遍歷即可。而B樹則需要對樹的每一層進行遍歷,這會需要更多的內存置換次數,因此也就需要花費更多的時間

19、Hash索引和B+樹所有有什麼區別或者說優劣呢?

首先要知道Hash索引和B+樹索引的底層實現原理:

hash索引底層就是hash表,進行查找時,調用一次hash函數就可以獲取到相應的鍵值,之後進行回表查詢獲得實際數據。B+樹底層實現是多路平衡查找樹。對於每一次的查詢都是從根節點出發,查找到葉子節點方可以獲得所查鍵值,然後根據查詢判斷是否需要回表查詢數據。

那麼可以看出他們有以下的不同:

  • hash索引進行等值查詢更快(一般情況下),但是卻無法進行範圍查詢。

因爲在hash索引中經過hash函數建立索引之後,索引的順序與原順序無法保持一致,不能支持範圍查詢。而B+樹的的所有節點皆遵循(左節點小於父節點,右節點大於父節點,多叉樹也類似),天然支持範圍。

  • hash索引不支持使用索引進行排序,原理同上。
  • hash索引不支持模糊查詢以及多列索引的最左前綴匹配。原理也是因爲hash函數的不可預測。AAAA和AAAAB的索引沒有相關性。
  • hash索引任何時候都避免不了回表查詢數據,而B+樹在符合某些條件(聚簇索引,覆蓋索引等)的時候可以只通過索引完成查詢。
  • hash索引雖然在等值查詢上較快,但是不穩定。性能不可預測,當某個鍵值存在大量重複的時候,發生hash碰撞,此時效率可能極差。而B+樹的查詢效率比較穩定,對於所有的查詢都是從根節點到葉子節點,且樹的高度較低。

因此,在大多數情況下,直接選擇B+樹索引可以獲得穩定且較好的查詢速度。而不需要使用hash索引。

20、數據庫爲什麼使用B+樹而不是B樹

(1)B樹只適合隨機檢索,而B+樹同時支持隨機檢索和順序檢索;

(2)B+樹空間利用率更高,可減少I/O次數,磁盤讀寫代價更低。一般來說,索引本身也很大,不可能全部存儲在內存中,因此索引往往以索引文件的形式存儲的磁盤上。這樣的話,索引查找過程中就要產生磁盤I/O消耗。B+樹的內部結點並沒有指向關鍵字具體信息的指針,只是作爲索引使用,其內部結點比B樹小,盤塊能容納的結點中關鍵字數量更多,一次性讀入內存中可以查找的關鍵字也就越多,相對的,IO讀寫次數也就降低了。而IO讀寫次數是影響索引檢索效率的最大因素;

(3)B+樹的查詢效率更加穩定。B樹搜索有可能會在非葉子結點結束,越靠近根節點的記錄查找時間越短,只要找到關鍵字即可確定記錄的存在,其性能等價於在關鍵字全集內做一次二分查找。而在B+樹中,順序檢索比較明顯,隨機檢索時,任何關鍵字的查找都必須走一條從根節點到葉節點的路,所有關鍵字的查找路徑長度相同,導致每一個關鍵字的查詢效率相當。

(4)B-樹在提高了磁盤IO性能的同時並沒有解決元素遍歷的效率低下的問題。B+樹的葉子節點使用指針順序連接在一起,只要遍歷葉子節點就可以實現整棵樹的遍歷。而且在數據庫中基於範圍的查詢是非常頻繁的,而B樹不支持這樣的操作。

(5)增刪文件(節點)時,效率更高。因爲B+樹的葉子節點包含所有關鍵字,並以有序的鏈表結構存儲,這樣可很好提高增刪效率。

21、B+樹在滿足聚簇索引和覆蓋索引的時候不需要回表查詢數據,

在B+樹的索引中,葉子節點可能存儲了當前的key值,也可能存儲了當前的key值以及整行的數據,這就是聚簇索引和非聚簇索引。 在InnoDB中,只有主鍵索引是聚簇索引,如果沒有主鍵,則挑選一個唯一鍵建立聚簇索引。如果沒有唯一鍵,則隱式的生成一個鍵來建立聚簇索引。

當查詢使用聚簇索引時,在對應的葉子節點,可以獲取到整行數據,因此不用再次進行回表查詢。

22、什麼是聚簇索引?何時使用聚簇索引與非聚簇索引

(1)聚簇索引:將數據存儲與索引放到了一塊,找到索引也就找到了數據

(2)非聚簇索引:將數據存儲於索引分開結構,索引結構的葉子節點指向了數據的對應行,myisam通過key_buffer把索引先緩存到內存中,當需要訪問數據時(通過索引訪問數據),在內存中直接搜索索引,然後通過索引找到磁盤相應數據,這也就是爲什麼索引不在key buffer命中時,速度慢的原因

澄清一個概念:innodb中,在聚簇索引之上創建的索引稱之爲輔助索引,輔助索引訪問數據總是需要二次查找,非聚簇索引都是輔助索引,像複合索引、前綴索引、唯一索引,輔助索引葉子節點存儲的不再是行的物理位置,而是主鍵值

何時使用聚簇索引與非聚簇索引

23、非聚簇索引一定會回表查詢嗎?

不一定,這涉及到查詢語句所要求的字段是否全部命中了索引,如果全部命中了索引,那麼就不必再進行回表查詢。

舉個簡單的例子,假設我們在員工表的年齡上建立了索引,那麼當進行select age from employee where age < 20的查詢時,在索引的葉子節點上,已經包含了age信息,不會再次進行回表查詢。

24、聯合索引是什麼?爲什麼需要注意聯合索引中的順序?

MySQL可以使用多個字段同時建立一個索引,叫做聯合索引。在聯合索引中,如果想要命中索引,需要按照建立索引時的字段順序挨個使用,否則無法命中索引。

具體原因爲:

MySQL使用索引時需要索引有序,假設現在建立了"name,age,school"的聯合索引,那麼索引的排序爲: 先按照name排序,如果name相同,則按照age排序,如果age的值也相等,則按照school進行排序。

當進行查詢時,此時索引僅僅按照name嚴格有序,因此必須首先使用name字段進行等值查詢,之後對於匹配到的列而言,其按照age字段嚴格有序,此時可以使用age字段用做索引查找,以此類推。因此在建立聯合索引的時候應該注意索引列的順序,一般情況下,將查詢需求頻繁或者字段選擇性高的列放在前面。此外可以根據特例的查詢或者表結構進行單獨的調整。

 

最後

歡迎關注公衆號:程序員追風,領取Java知識點學習思維導圖總結+一線大廠Java面試題總結+一份300頁pdf文檔的Java核心知識點總結!

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章