2022年MySQL最新面試題2篇 - 索引

大家好，我是漫步coding, 最近在整理2022年MySQL最新面試題, 大家也可以通過我下面的博客地址在線閱讀, 今天講講第2篇: ?索引。本文首發于公眾號: 漫步coding

MySql數據庫基礎知識

MySQL索引

MySQL存儲引擎

MySQL事務

MySql數據庫讀寫鎖

MySQL視圖

MySQL觸發器

MySQL數據庫優化

MySQL部署和運維

1、索引有哪些使用場景（重點）

2、索引的數據結構（b樹，hash）

3、創建索引的原則是什么?（重中之重）

4、使用索引查詢一定能提高查詢的性能嗎？為什么

5、索引有哪些優缺點？

6、講一講聚簇索引與非聚簇索引？

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

8、什么是最左前綴原則？什么是最左匹配原則

9、數據庫為什么使用B+樹而不是B樹

10、非聚簇索引一定會回表查詢嗎？

11、有哪些情況, 索引會失效, 可以簡單說說嗎?

出現概率: ★★★★★

1)、應該創建索引的場景

主鍵應該創建主鍵索引。

頻繁作為查詢條件的字段應該創建索引。

查詢中需要與其他表進行關聯的字段應該創建索引。

需要排序的字段應該創建索引。

需要統計或分組的字段應該創建索引。

優先考慮創建復合索引。

2)、不應創建索引的場景

數據記錄較少的表。

經常需要增刪改操作的字段。

數據記錄重復較多且分布平均的字段（如性別、狀態等）。

索引的選擇性是指索引列中不同值的數目與表中記錄總數的比。

索引的選擇性越接近于1，創建索引的價值就越高。反之就越低。

出現概率: ★★★★★

從存儲結構上來劃分：BTree索引（B-Tree或B+Tree索引），Hash索引，full-index全文索引，R-Tree索引。這里所描述的是索引存儲時保存的形式，MySQL默認采用的B+Tree， 這里主要講講B+樹的特點:

1.非葉子節點不存儲data，只存儲索引(冗余)，可以放更多的索引

2.葉子節點包含所有索引字段

3.葉子節點用指針連接，提高區間訪問的性能 （快速定位范圍查詢，例如查詢大于20，第一次io從根節點查詢三次定位到20，然后通過后面的指針查詢大于20的數據，就不用再從根節點的重新再查詢，提高性能，葉子節點開始結束節點也是用指針連接串起來的）

出現概率: ★★★★

1)、選擇唯一性索引

2)、為經常需要排序、分組和聯合操作的字段建立索引

3)、為常作為查詢條件的字段建立索引

4)、限制索引的數目

索引的數目不是越多越好。每個索引都需要占用磁盤空間，索引越多，需要的磁盤空間就越大。修改表時，對索引的重構和更新很麻煩。越多的索引，會使更新表變得很浪費時間。

5)、盡量使用數據量少的索引

如果索引的值很長，那么查詢的速度會受到影響。例如，對一個CHAR(100)類型的字段進行全文檢索需要的時間肯定要比對CHAR(10)類型的字段需要的時間要多。

6)、盡量使用前綴來索引

如果索引字段的值很長，最好使用值的前綴來索引。例如，TEXT和BLOG類型的字段，進行全文檢索會很浪費時間。如果只檢索字段的前面的若干個字符，這樣可以提高檢索速度。

7)、最左前綴匹配原則

8)、查詢時使用計算，會導致索引失效

出現概率: ★★★★

不是所有的查詢使用查詢都能提高性能， 比如下面幾個案例

像 like % xxx% 、不滿足最左匹配原則的情況下并不能使用到建好的索引

MySQL 在可以使用多個索引的情況下，查詢優化器會根據查詢范圍的數據量估算索引代價，最壞的是估算完畢后，發現這些索引的字段區分度不高，還不如掃全表，于是 Mysql 掃全表了

如果索引的列比需要查詢的列少，Mysql 會通過聚簇索引回表查詢其他字段

如果索引的字段很大，每個頁能存的條目就很少，讀取時 IO 會消耗更多，頁 Buffer 輪替的更快

出現概率: ★★★

1)、索引的優點

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

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

2)、索引的缺點

時間方面：創建索引和維護索引要耗費時間，具體地，當對表中的數據進行增加、刪除和修改的時候，索引也要動態的維護，會降低增/改/刪的執行效率；

空間方面：索引需要占物理空間。

出現概率: ★★★★

在 InnoDB 里，索引B+Tree的葉子節點存儲了整行數據的是主鍵索引，也被稱之為聚簇索引，即將數據存儲與索引放到了一塊，找到索引也就找到了數據。

而索引B+Tree的葉子節點存儲了主鍵的值的是非主鍵索引，也被稱之為非聚簇索引、二級索引。

聚簇索引與非聚簇索引的區別：

非聚集索引與聚集索引的區別在于非聚集索引的葉子節點不存儲表中的數據，而是存儲該列對應的主鍵（行號）

對于InnoDB來說，想要查找數據我們還需要根據主鍵再去聚集索引中進行查找，這個再根據聚集索引查找數據的過程，我們稱為回表。第一次索引一般是順序IO，回表的操作屬于隨機IO。需要回表的次數越多，即隨機IO次數越多，我們就越傾向于使用全表掃描 。

通常情況下， 主鍵索引（聚簇索引）查詢只會查一次，而非主鍵索引（非聚簇索引）需要回表查詢多次。當然，如果是覆蓋索引的話，查一次即可

注意：MyISAM無論主鍵索引還是二級索引都是非聚簇索引，而InnoDB的主鍵索引是聚簇索引，二級索引是非聚簇索引。我們自己建的索引基本都是非聚簇索引。

出現概率: ★★★

方法一:

索引是單獨的文件，增刪改時，當存在索引，會消耗額外io。刪除速度和索引數量成正比

刪除索引

刪除需要刪除的數據

重新建立索引

這個方法有一個很明顯的缺點, 就是在正式環境這個表如果訪問頻率比較高的話， 刪除索引后有大量的SQL查詢會導致數據庫IO和CPU特別高

方法二:

之前我在正式環境的做法是 將刪除任務拆分為一次刪除1w條， 然后把刪除任務重新壓入的異步任務隊列里面。

出現概率: ★★★★

在mysql建立聯合索引時會遵循最左前綴匹配的原則，即最左優先，在檢索數據時從聯合索引的最左邊開始匹配，示例：

對列col1、列col2和列col3建一個聯合索引

KEY test_col1_col2_col3 on test(col1,col2,col3);

聯合索引 test_col1_col2_col3 實際建立了(col1)、(col1,col2)、(col,col2,col3)三個索引。

SELECT * FROM test WHERE col1=“1” AND clo2=“2” AND clo4=“4”

上面這個查詢語句執行時會依照最左前綴匹配原則，檢索時會使用索引(col1,col2)進行數據匹配。

出現概率: ★★★

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

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

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

使用B+樹的好處

由于B+樹的內部節點只存放鍵，不存放值，因此，一次讀取，可以在內存頁中獲取更多的鍵，有利于更快地縮小查找范圍。

B+樹的葉節點由一條鏈相連，因此，當需要進行一次全數據遍歷的時候，B+樹只需要使用O(logN)時間找到最小的一個節點，然后通過鏈進行O(N)的順序遍歷即可。而B樹則需要對樹的每一層進行遍歷，這會需要更多的內存置換次數，因此也就需要花費更多的時間。

數據庫的數據讀取都是需要進行代價巨大的磁盤IO操作，因此，更快地縮小范圍和更少的讀取次數是數據庫需要關注的重點。而B+樹在這些點上比B樹做的更好。這就是為什么數據庫要選用B+樹作為底層實現。

出現概率: ★★★

不一定，這涉及到查詢語句所要求的字段是否全部命中了索引，如果全部命中了索引，那么就不必再進行回表查詢。一個索引包含（覆蓋）所有需要查詢字段的值，被稱之為"覆蓋索引"。

舉個簡單的例子，假設我們在學生表的成績上建立了索引，那么當進行select score from student where score > 90的查詢時，在索引的葉子節點上，已經包含了score 信息，不會再次進行回表查詢。

也歡迎關注我的公眾號:?漫步coding, 回復:?mysql免費獲取最新Mysql面試題匯總(含答案)。一起交流, 在coding的世界里漫步。

MySQL 數據庫

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。