大廠面試MySQL高頻20問：索引+事務+優化全覆蓋

背景介紹

說實話，MySQL這塊我之前一直覺得自己還行，畢竟日常CRUD寫了兩年多，索引也加過不少。但真正到了大廠面試的時候，才發現自己理解的太淺了。面試官一追問底層原理，我就開始支支吾吾。後來我花了整整三週時間，把MySQL高頻題全部過了一遍，整理出這20道最常考的題目，希望能幫到正在準備面試的你。

一、索引（6題）

1. B+樹原理？為什麼MySQL用B+樹而不是B樹？

考察點：索引底層資料結構理解

B+樹是B樹的變體，關鍵區別在於：所有資料都存在葉子節點，非葉子節點只存索引；葉子節點之間通過雙向鏈表連接。MySQL選擇B+樹的原因有三：一是樹的高度更低，IO次數更少，因為非葉子節點不存資料，同樣大小的頁能存更多索引項；二是範圍查詢效率高，葉子節點鏈表可以直接順序掃描；三是查詢效能穩定，每次都要走到葉子節點，不會像B樹那樣有時快有時慢。

2. 聚簇索引和非聚簇索引的區別？

考察點：索引組織方式理解

聚簇索引就是InnoDB的主鍵索引，葉子節點直接存儲整行資料，資料和索引在一起，所以一張表只能有一個聚簇索引。非聚簇索引（二級索引）的葉子節點存的是主鍵值，查詢時如果需要的列不在索引中，需要回表——也就是拿著主鍵值再去聚簇索引查一遍。這也是為什麼覆蓋索引能提升效能，因為避免了回表操作。

3. 什麼是覆蓋索引？

考察點：索引優化策略

覆蓋索引就是查詢所需要的所有列都包含在索引中，不需要回表。比如表上有聯合索引(a,b)，執行SELECT a,b FROM t WHERE a=1，索引已經包含了a和b，直接從索引返回資料就行。面試官特別愛問這個，因為這是實際優化中最常用的手段之一。我之前優化過一個慢查詢，就是通過添加覆蓋索引把查詢時間從800ms降到了5ms。

4. 最左匹配原則是什麼？

考察點：聯合索引使用規則

聯合索引(a,b,c)的匹配規則是從最左邊的列開始，遇到範圍查詢(>、<、between、like前綴)會停止匹配。也就是說WHERE a=1 AND b=2 AND c>3只能用到a、b、c三列，但WHERE a=1 AND c=3只能用到a列，b列跳過了c也用不上。還有一點容易忽略：索引列的順序不依賴WHERE中的書寫順序，優化器會自動調整。

5. 索引失效的場景有哪些？

考察點：索引使用條件判斷

這個題面試必問！常見的失效場景：對索引列使用函數或運算（WHERE YEAR(create_time)=2025）；隱式類型轉換（varchar列用int查）；LIKE以通配符開頭（LIKE '%abc'）；OR條件中有一列無索引；不滿足最左匹配；NOT IN、NOT EXISTS在某些情況下。我面試位元組的時候，面試官就讓我列舉5種以上，還好我準備得充分。

6. 如何做索引優化？

考察點：實際優化能力

索引優化的核心思路：優先考慮覆蓋索引減少回表；聯合索引遵循最左匹配且把區分度高的列放前面；避免在索引列上做運算；用EXPLAIN分析執行計劃看type和Extra欄位；對於ORDER BY和GROUP BY也要考慮索引。另外別忘了，索引不是越多越好，每個索引都要維護，寫入效能會下降。

二、事務（5題）

7. ACID是什麼？

考察點：事務基本特性

原子性（Atomicity）通過undo log實現，事務要麼全部成功要麼全部回滾；一致性（Consistency）是目標，由其他三個特性共同保證；隔離性（Isolation）通過鎖和MVCC實現；持久性（Durability）通過redo log實現。面試官經常追問的是：一致性能不能只靠資料庫保證？答案是不能，還需要應用層約束，比如轉帳場景餘額不能為負。

8. 四種隔離級別？MySQL預設哪個？

考察點：事務隔離機制

讀未提交（髒讀）、讀已提交（不可重複讀）、可重複讀（幻讀）、串列化。MySQL預設可重複讀（RR）。RR級別下，InnoDB通過MVCC+間隙鎖解決了大部分幻讀問題，但不是全部——快照讀不會幻讀，當前讀可能幻讀。面試官最愛追問的就是這個「不是全部」的細節。

9. MVCC原理？

考察點：並發控制機制

MVCC通過隱藏列（trx_id、roll_pointer）、undo log版本鏈和ReadView實現。每行資料有兩個隱藏列：事務ID和回滾指標。ReadView包含當前活躍事務ID列表，通過比較版本鏈上每個版本的事務ID和ReadView來判斷可見性。RC級別每次SELECT生成新ReadView，RR級別只在第一次SELECT生成。這個機制讓我真正理解了為什麼RR能解決不可重複讀。

10. InnoDB的鎖機制？

考察點：鎖類型和使用場景

按粒度分：表鎖、行鎖、間隙鎖、臨鍵鎖（Next-Key Lock=行鎖+間隙鎖）。按模式分：共享鎖（S）、排他鎖（X）、意向鎖。InnoDB的行鎖是加在索引上的，如果沒有用到索引，行鎖會退化為表鎖。臨鍵鎖是InnoDB在RR級別下防止幻讀的關鍵，鎖定的是索引記錄及其前面的間隙。

11. 死鎖怎麼產生？如何避免？

考察點：死鎖處理能力

死鎖產生的四個必要條件：互斥、持有並等待、不可搶佔、循環等待。InnoDB檢測到死鎖會自動回滾代價最小的事務。避免死鎖的方法：按固定順序訪問表和行；大事務拆小事務；降低隔離級別；添加合理索引避免鎖升級。我之前在生產環境遇到過一次死鎖，就是兩個事務以不同順序更新同一批行導致的，後來統一了更新順序就解決了。

三、日誌（3題）

12. redo log是什麼？

考察點：崩潰恢復機制

redo log是InnoDB的物理日誌，記錄的是「在某個資料頁上做了什麼修改」，用於崩潰恢復保證持久性。採用WAL（Write-Ahead Logging）策略，先寫日誌再寫磁碟。redo log是固定大小的循環寫入，由ib_logfile0和ib_logfile1組成。面試官可能會追問：為什麼先寫redo log而不是直接寫資料檔案？因為redo log是順序寫，效能遠高於資料檔案的隨機寫。

13. undo log是什麼？

考察點：事務回滾機制

undo log記錄的是資料修改前的值，用於事務回滾保證原子性，同時也是MVCC版本鏈的核心組成部分。insert產生insert undo log（事務提交後可刪除），update/delete產生update undo log（需要保留給其他事務做快照讀）。這就是為什麼長事務會導致undo log膨脹，進而影響效能。

14. binlog和redo log的區別？

考察點：日誌體系理解

binlog是Server層的邏輯日誌，記錄所有DDL和DML操作，主要用於主從複製和資料恢復；redo log是InnoDB層的物理日誌，記錄頁的物理修改，用於崩潰恢復。關鍵區別：binlog是追加寫入，redo log是循環寫入；binlog有兩種格式（statement/row），redo log只有物理格式；事務執行過程中redo log持續寫入，binlog在事務提交時一次性寫入。兩階段提交就是協調這兩個日誌的一致性。

四、優化（3題）

15. 慢查詢如何優化？

考察點：效能調優實戰

第一步開啟慢查詢日誌定位慢SQL；第二步用EXPLAIN分析執行計劃，重點關注type（避免ALL全表掃描）、key（是否命中索引）、rows（掃描行數）、Extra（是否Using filesort/Using temporary）；第三步針對性優化：添加索引、優化SQL寫法、避免SELECT *、分解大查詢。我之前遇到一個案例，一個分頁查詢在資料量大時特別慢，用延遲關聯優化後從3秒降到50毫秒。

16. 分庫分表怎麼做？

考察點：架構設計能力

垂直分庫按業務拆分，水平分庫按規則（如使用者ID取模）拆分。分表同理。常用中介軟體有ShardingSphere和MyCat。分庫分表帶來的問題：分散式事務、跨庫JOIN、全域ID生成、資料遷移。面試官通常會追問：什麼時候該分？一般單表超過2000萬行或資料檔案超過20GB就該考慮了。但分庫分表是最後的手段，先試索引優化、讀寫分離、快取。

17. 讀寫分離怎麼做？

考察點：架構方案設計

基於主從複製實現，主庫負責寫，從庫負責讀。程式碼層面可以通過Spring的AbstractRoutingDataSource或ShardingSphere實現動態資料來源切換。需要注意的問題：主從延遲導致讀到舊資料（關鍵業務可以強制走主庫）、事務中的讀寫要在同一個資料來源。一般延遲在毫秒級，但對於金融場景可能不可接受。

五、其他（3題）

18. 主從複製原理？

考察點：高可用架構理解

三個執行緒：主庫的Binlog Dump執行緒（發送binlog）、從庫的IO執行緒（接收並寫入relay log）、從庫的SQL執行緒（執行relay log）。三種同步模式：非同步複製（預設，可能丟資料）、半同步複製（至少一個從庫確認收到）、全同步複製（所有從庫確認，效能差）。面試官經常問：主從延遲怎麼解決？答案：並行複製、半同步、業務層強制讀主庫。

19. 一條SQL的執行流程？

考察點：MySQL整體架構理解

連接器→查詢快取（8.0已移除）→分析器（詞法語法分析）→優化器（選擇執行計劃）→執行器（呼叫儲存引擎介面）→儲存引擎（返回資料）。更新語句還涉及redo log和binlog的兩階段提交：先寫redo log（prepare狀態）→寫binlog→提交redo log（commit狀態）。這個流程圖我畫了不下十遍才真正記住。

20. InnoDB和MyISAM的區別？

考察點：儲存引擎選型

InnoDB支援事務、行鎖、外來鍵、MVCC、崩潰恢復；MyISAM不支援事務和行鎖，只有表鎖，但SELECT效能在某些場景下更好，COUNT(*)不需要遍歷。現在基本都用InnoDB，MySQL5.5之後預設引擎就是InnoDB。唯一還在用MyISAM的場景可能就是隻讀的配置表了。

心得建議

準備MySQL面試，我的建議是：先理解整體架構（一條SQL怎麼執行的），再深入各個模組（索引、事務、日誌），最後串聯起來。光背答案是不夠的，面試官會不斷追問，只有真正理解了原理才能應對。建議配合原始碼閱讀和實際操作，比如用EXPLAIN分析各種SQL的執行計劃，手動製造死鎖場景觀察現象，這些實戰經驗面試時特別加分。

FAQ

Q：MySQL面試需要看原始碼嗎？
一般不需要，但了解關鍵資料結構（如Buffer Pool、B+樹節點結構）的原始碼實現會非常加分。

Q：索引優化有什麼快速上手的方法？
先學會看EXPLAIN的輸出，理解type和Extra欄位，然後對著慢查詢日誌逐個優化。

Q：事務隔離級別面試怎麼準備？
重點理解RR級別下MVCC的實現原理，以及間隙鎖如何防止幻讀，這是面試最高頻的追問點。