很多 Java 開發者面試前都會做一件事瘋狂刷 MySQL 八股文。索引、事務、MVCC、explain、慢查詢……背得滾瓜爛熟結果真到了面試現場面試官換一個問法就答不上來。原因很簡單你背的是答案不是解決問題的思路。MySQL 在 Java 技術棧里太重要了。它幾乎是國內互聯網公司的標配數據庫而 Java 面試中 MySQL 相關問題的出現頻率常年排在 JVM、并發、Spring 之后的第一梯隊。面試官問 MySQL不是在考你記性好不好而是想確認兩件事第一你寫出來的 SQL 是不是真的能扛住生產環境的并發和壓力第二系統出了問題你是兩眼一抹黑還是能順著日志和鎖機制快速定位。這篇文章不會把網上能找到的所有 MySQL 面試題都抄一遍。我會從「面試官實際考察點」出發把 MySQL 面試高頻考點拆成幾個核心模塊——存儲引擎、索引、事務、鎖、日志、SQL 優化、主從復制——每個模塊都講清楚原理、常見問法、容易踩的坑以及面試官期待的回答邏輯。如果你正在準備 Java 面試建議按照文末的 3 天復習路線來規劃 MySQL 部分?？赐赀@篇文章你能建立一張完整的 MySQL 考點地圖后面再看到任何一道 MySQL 面試題你都能立刻判斷它考的是哪個模塊、應該從哪些角度回答。1. 面試前的 MySQL 考點地圖先知道考什么再決定學什么很多準備面試的人有一個習慣打開搜索框搜「MySQL 面試題」然后照著長篇大論的題庫從頭刷到尾。這樣做的效率極低因為你把時間平均分配給了高頻題和冷門題最后記住的反而是最不常考的東西。MySQL 面試題可以按考察頻率和重要性分成三層。第一層是必考題。索引的原理和失效場景、事務的 ACID 和隔離級別、MVCC 的實現機制、InnoDB 和 MyISAM 的區別。這四塊內容幾乎每家公司的面試都會問到而且經常是連環追問。比如面試官先問「為什么 InnoDB 用 B 樹」你答完索引結構后他又會追問「那最左前綴原則是怎么回事」「什么情況下索引會失效」「覆蓋索引和回表是什么」。這些問題的底層知識是連在一起的。第二層是高概率題。SQL 優化和慢查詢排查、行鎖與表鎖、死鎖的原因和排查、redo log 和 binlog 的區別與兩階段提交、主從復制的原理。如果面試的是高級崗位或者面試官想考察你有沒有真實項目經驗這些內容會很自然地出現在對話里。第三層是加分題。MySQL 8 的新特性、int(5) 的含義、utf8mb4 字符集的選擇、連接數、Buffer Pool 等參數調優思路。這些內容不一定每家都問但答好了能明顯提升面試官對你的印象。這篇文章的正文就按照這個分層來展開。你現在要做的不是馬上開始背答案而是先跟著這篇文章把每個模塊的核心原理搞清楚。原理懂了面試現場不管問題怎么變你都能用底層邏輯去回答。2. MySQL 存儲引擎為什么 InnoDB 成了事實標準存儲引擎幾乎是 MySQL 面試的第一個話題因為它是理解后續所有內容的基礎。MyISAM 和 InnoDB 的對比是經典送分題但很多人答不完整總是在枚舉特性沒有講清楚「為什么」。2.1 MyISAM 和 InnoDB 的核心區別先看一張對比表對比維度MyISAMInnoDB事務支持不支持支持 ACID 事務鎖粒度表級鎖行級鎖 表級鎖外鍵不支持支持索引結構B 樹非聚簇聚簇索引 二級索引崩潰恢復恢復能力弱借助 redo log 實現崩潰恢復全文索引支持MySQL 5.6 起支持存儲文件.frm .MYD .MYI.frm .ibd或共享表空間光記住這張表還不夠。面試官更關注的是你知道這些區別對實際開發有什么影響2.2 面試官追問為什么現在默認用 InnoDB這個問題的標準回答思路是「因為業務場景需要事務和并發控制」?；ヂ摼W業務的典型場景是用戶下單扣庫存、轉賬、訂單狀態變更這些操作必須保證一致性。以轉賬為例A 賬戶扣錢和 B 賬戶加錢必須同時成功或同時失敗。MyISAM 不支持事務一個 UPDATE 執行到一半系統崩潰數據就處于中間狀態沒有人知道應該回滾還是繼續。InnoDB 通過事務和 redo/undo 日志解決了這個問題。并發控制是另一個關鍵點。MyISAM 使用表級鎖意味著對一張表的任何寫操作都會鎖住整張表。在低并發場景下問題不大但互聯網業務動輒上千的 QPS一個 UPDATE 鎖住整張表后面所有讀寫請求都會被阻塞性能會斷崖式下降。InnoDB 的行級鎖只鎖定涉及的行其他行的讀寫完全不受影響。還有一個隱藏點InnoDB 在崩潰恢復方面遠勝于 MyISAM。數據庫宕機后InnoDB 可以通過 redo log 重放未完成的事務保證數據不丟失MyISAM 則可能直接出現表損壞需要長時間修復。2.3 MyISAM 還有沒有用武之地這個問題屬于加分項。MyISAM 在某些場景下仍有一點價值表數據極少、完全只讀、不需要事務、并發極低的歷史歸檔表。它的索引結構更簡單某些全表掃描場景下可能更快。但從 MySQL 8.0 開始MyISAM 被進一步邊緣化官方建議所有新業務都使用 InnoDB?；卮饡r可以說「從技術選型上我不會再選 MyISAM除非是極特殊的歷史只讀場景?！?. 索引MySQL 面試的半壁江山索引是 MySQL 面試中占比最大、追問最深的一塊。如果把 Java 面試比作一場考試索引就是最后的壓軸大題前面的基礎題答得再好壓軸題答崩了照樣掛。3.1 為什么是 B 樹而不是 B 樹、哈希表先想一個問題數據庫索引到底要解決什么問題答案是在數據量很大的情況下快速定位數據。磁盤讀取很慢一次磁盤 I/O 能讀到的數據有限如果每次查找都做很多次隨機磁盤 I/O系統性能會廢掉。B 樹就是為此設計的。B 樹和 B 樹的區別要從兩個維度看。第一B 樹的非葉子節點不存儲數據只存儲鍵值和指針。這意味著每個非葉子節點能容納更多的鍵樹的高度更矮。一棵 3 層的 B 樹可以存儲千萬級甚至上億條數據而查詢只需要 3 次左右的磁盤 I/O。B 樹的非葉子節點也存數據同樣的數據量樹會更高I/O 次數更多。第二B 樹的所有數據都存儲在葉子節點并且葉子節點之間有鏈表相連天然支持范圍查詢。WHERE age 20 AND age 30 這樣的條件在 B 樹上找到一個起點后可以順著鏈表依次掃描。B 樹的葉子節點沒有鏈表范圍查詢需要回到樹中間做中序遍歷性能遠不如 B 樹。那哈希表呢哈希索引的查找復雜度是 O(1)單行查詢非?？斓袃蓚€致命問題不支持范圍查詢、不支持排序。哈希表是一一映射age 20 這種操作需要把所有數據都哈希一遍完全走不了索引。所以 MySQL 的 InnoDB 引擎在絕大多數場景下都使用 B 樹哈希索引只存在于自適應哈希索引這種輔助結構中。3.2 聚簇索引、二級索引和回表這是面試里最容易被問懵的一組概念但它們非常重要因為直接關系到 SQL 的性能。InnoDB 的表數據本身就是索引結構。聚簇索引的葉子節點存儲的是完整的行數據所以一個表只能有一個聚簇索引。默認情況下InnoDB 會用主鍵作為聚簇索引如果表沒有主鍵InnoDB 會選一個非空唯一索引再不行就用隱藏的 rowid 生成一個。二級索引也叫非聚簇索引的葉子節點存儲的是索引列的值和主鍵值。當你要通過二級索引查數據時流程是先查二級索引找到主鍵再用主鍵回聚簇索引查完整行數據。這個「用主鍵再查一次」的過程就叫回表。舉個例子-- 表 person主鍵 id二級索引 idx_name SELECT * FROM person WHERE name 張三;執行過程分兩步第一步通過 idx_name 索引找到 name 為「張三」的記錄得到主鍵 id第二步用 id 回到聚簇索引取出完整記錄。如果 name 索引覆蓋了你要查的所有字段那就不用回表了這就是覆蓋索引。覆蓋索引是 SQL 優化的常用手段。比如SELECT id, name FROM person WHERE name 張三idx_name 索引里既有 name 又有 id直接查索引導出結果不需要回表。面試官問「怎么優化 SQL」你答一句「用覆蓋索引避免回表」他立刻知道你有實戰經驗。3.3 最左前綴原則聯合索引 (a, b, c) 在匹配時會遵守最左前綴原則查詢條件必須從最左邊的列開始連續匹配。WHERE a 1、WHERE a 1 AND b 2、WHERE a 1 AND b 2 AND c 3都能走索引但WHERE b 2或WHERE c 3走不了。這個原則背后是 B 樹的結構決定的。聯合索引的排序規則是先按 a 排a 相同再按 b 排b 相同再按 c 排。所以你想直接跳過 a 用 b 查詢索引順序上 b 不是全局有序的沒法用二分查找。實際開發中最常見的坑是建了聯合索引但查詢條件的順序不對。WHERE b 2 AND a 1其實能走索引因為 MySQL 查詢優化器會自動調整條件順序。真正讓索引失效的是WHERE a 1 AND c 3c 跳過了 b只能用 a 來縮小范圍c 的篩選就要回表后做了。3.4 索引失效的常見場景面試官問索引失效通常是在考察你寫 SQL 時有沒有基本意識。高頻失效場景包括對索引列使用函數或表達式如WHERE UPPER(name) ZHANG、WHERE age 1 30隱式類型轉換如索引列是字符串類型查詢條件用數字使用 LIKE 且通配符在開頭如WHERE name LIKE %張OR 連接非索引列聯合索引不滿足最左前綴原則回答時可以補一句「索引失效不是絕對的最終以執行計劃為準」然后拿出 explain 來驗證。這種回答方式明顯比死記硬背更有說服力。4. 事務與隔離級別臟讀、不可重復讀、幻讀的底層邏輯事務是 MySQL 面試必考內容只背四個隔離級別不夠要理解每個隔離級別解決的問題以及 InnoDB 是怎么實現隔離的。4.1 ACID 到底在說什么事務有四個特性原子性Atomicity、一致性Consistency、隔離性Isolation、持久性Durability。面試官喜歡讓候選人用自己的話解釋這四個概念目標是看你能不能把抽象概念講得清晰。原子性一個事務里的所有操作要么全部成功要么全部失敗不能只做一半。比如轉賬 100 元A 扣錢成功但 B 加錢失敗整個事務就要回滾到轉賬前狀態。一致性事務執行前后數據都處于合法狀態。這個特性最抽象底層依賴原子性、隔離性和持久性共同保證。舉個例子轉賬前后A 和 B 的賬戶余額總和不變。隔離性多個事務并發執行時互相之間不能產生干擾。比如兩個人同時改同一條訂單記錄事務隔離要保證他們看到的數據是合理的。持久性事務提交后修改必須永久保存即使數據庫崩潰也不能丟。InnoDB 通過 redo log 實現這一點。4.2 四種隔離級別與三類問題SQL 標準定義了四種隔離級別隔離級別臟讀不可重復讀幻讀讀未提交READ UNCOMMITTED可能可能可能讀已提交READ COMMITTED不會可能可能可重復讀REPEATABLE READ不會不會可能串行化SERIALIZABLE不會不會不會先解釋三個問題臟讀事務 A 修改了一條數據還沒提交事務 B 讀到了這條修改后的數據事務 A 回滾事務 B 讀到的數據就是臟數據。不可重復讀事務 A 先讀取 id1 的記錄然后事務 B 修改并提交了這條記錄事務 A 再讀一次發現數據變了。同一個事務內兩次讀取結果不一致?；米x事務 A 查詢某條件下的記錄集合事務 B 插入了一條滿足該條件的新記錄并提交事務 A 再次查詢時發現結果集合多了一行像「幻覺」一樣。MySQL 默認隔離級別是可重復讀REPEATABLE READ。InnoDB 通過 MVCC 和間隙鎖在可重復讀級別下解決了幻讀問題這是它和標準 SQL 術語的一個差異點也是面試中很有含金量的一句話。4.3 MVCC多版本并發控制的核心機制MVCC 全稱 Multi-Version Concurrency Control多版本并發控制。它的核心思想是讀寫不互相阻塞。寫事務修改數據時讀事務仍然可以讀到之前版本的數據前提是隔離級別允許讀舊版本。InnoDB 在每行數據后面隱藏了兩個字段trx_id最近修改該行的事務 id和 roll_pointer指向 undo log 中的舊版本鏈。當一個事務要讀取某行時它會檢查自己的 Read View判斷哪些版本對它可見。Read View 是一個事務啟動時生成的快照里面記錄了系統中活躍事務的 id 列表。判斷規則大致是如果行的 trx_id 小于 Read View 中最小活躍事務 id說明這個版本在 Read View 生成前已經提交可見如果 trx_id 大于最大活躍事務 id說明這個版本在 Read View 生成后才創建不可見如果 trx_id 在活躍列表中說明該版本對應的修改事務還未提交不可見需要沿 undo log 找更早的版本。這就是可重復讀的實現原理事務在第一次讀取時生成 Read View之后每次讀取都用同一個 Read View所以同一事務內多次讀取結果一致。而讀已提交級別每次讀取都會生成新的 Read View所以能讀到其他事務新提交的數據?；卮?MVCC 時能畫出 Read View 的判斷邏輯就比單純背誦「MVCC 解決了讀寫阻塞問題」要高一個檔次。5. 鎖機制與死鎖排查從行鎖到間隙鎖鎖是和事務并發強相關的主題。面試官問鎖通常不是要你背鎖的類型列表而是考察你在高并發場景下能不能判斷出哪一類鎖可能導致性能問題、死鎖怎么發生、怎么排查。5.1 行鎖、表鎖、意向鎖InnoDB 支持行級鎖和表級鎖。行級鎖粒度小、并發度高但有加鎖開銷表級鎖粒度大、并發度低適合整表操作。InnoDB 默認使用行級鎖但某些場景下 MySQL 會升級為表鎖比如需要掃描全表才能執行 UPDATE 時。意向鎖比較抽象。它的作用是快速判斷表里是否有行被鎖住。事務要給某行加鎖前必須先給表加意向鎖。這就避免了另一個事務加表鎖時需要逐行掃描看是否有行鎖沖突。意向鎖之間是兼容的意向鎖與表級排他鎖沖突。5.2 記錄鎖、間隙鎖、臨鍵鎖這部分是 InnoDB 鎖的核心細節也是一個比較難講清楚的知識點。三類行鎖對應的場景不同。記錄鎖Record Lock鎖定的是索引記錄本身。SELECT * FROM t WHERE id 1 FOR UPDATE會對 id1 的記錄加鎖其他事務要修改這一行必須等待。間隙鎖Gap Lock鎖定的是索引記錄之間的間隙用于防止其他事務在間隙中插入新記錄從而解決幻讀問題。比如索引里有 1、3、5 三行間隙鎖可能鎖住 (1,3) 這個區間其他事務不能插入 id2 的記錄。臨鍵鎖Next-Key Lock是記錄鎖和間隙鎖的組合鎖定的范圍包括當前記錄以及其前面的間隙。例如 (1,3] 表示鎖住 3 這條記錄以及 (1,3) 的間隙。InnoDB 在可重復讀級別下默認使用臨鍵鎖來防止幻讀。面試官問死鎖時常用場景是兩個事務互相持有對方需要的鎖。比如事務 A 更新了 id1 的行事務 B 更新了 id2 的行然后 A 請求更新 id2B 請求更新 id1兩個事務互相等待死鎖就出現了?；卮饡r可以補充一句InnoDB 有死鎖檢測機制發現死鎖后會回滾代價較小的事務讓另一個事務繼續執行。5.3 死鎖排查思路真實項目中死鎖不是像上面例子那樣剛好反向更新兩條記錄更多是因為范圍鎖、間隙鎖疊加導致。排查死鎖的第一步是查看死鎖日志SHOW ENGINE INNODB STATUS;執行后重點看 LATEST DETECTED DEADLOCK 部分里面會顯示兩個事務各持有什么鎖、在等待什么鎖。根據這幾條信息通常能定位到是哪兩個事務發生了互相等待。死鎖的預防手段包括所有事務按固定順序訪問資源、盡量縮短事務時間、合理設計索引避免掃描范圍過大、用低隔離級別減少間隙鎖。6. MySQL 三大日志redo log、undo log、binlog 的配合日志是 MySQL 面試中偏難的一部分因為涉及數據庫底層工作機制。很多候選人能背出三個日志的名字但說不清它們各自的職責和協作關系。6.1 三者的核心職責redo log 是重做日志屬于 InnoDB 存儲引擎層。它的作用是保證事務的持久性。當你執行一條 UPDATE 時InnoDB 不會立刻把數據頁刷寫到磁盤因為磁盤隨機寫太慢。它會先把修改記錄寫到 redo log 中這是順序寫速度快得多。事務提交時只要 redo log 刷到磁盤事務就算持久化了數據頁可以以后慢慢刷。如果數據庫在數據頁刷盤前崩潰重啟后 InnoDB 會通過 redo log 重放操作恢復數據。undo log 是回滾日志也屬于 InnoDB 存儲引擎層。它保存了事務修改前的數據版本用于事務回滾和 MVCC 的多版本鏈。事務執行中需要回滾時通過 undo log 把數據恢復到修改前狀態。同時MVCC 中提到的舊版本讀取就是通過 undo log 回溯歷史版本實現的。binlog 是二進制日志屬于 MySQL Server 層記錄的是數據的邏輯變更比如「id1 的行的 age 從 20 改成 30」。binlog 的主要用途有三個主從復制、數據恢復、審計。主從架構中從庫通過拉取主庫的 binlog 并在本地重放實現與主庫數據一致。6.2 為什么需要兩階段提交redo log 和 binlog 是兩個獨立的日志系統分別記錄在當前事務里。問題來了如果 redo log 寫了但 binlog 沒寫或者反過來主庫和從庫的數據就會不一致。舉一個例子事務執行到一半redo log 寫入成功并提交但 binlog 還沒來得及寫數據庫在此時崩潰。重啟后主庫通過 redo log 恢復了更新但從庫沒有收到 binlog就沒有更新。主從數據不一致。為了解決這個問題InnoDB 引入了兩階段提交事務在提交時先寫 redo log進入 prepare 狀態然后寫 binlog最后把 redo log 改為 commit 狀態。如果在 prepare 階段后、binlog 寫入前崩潰重啟后發現 redo log 是 prepare 但 binlog 未寫就會回滾事務如果 binlog 已寫、準備提交 redo log 前崩潰重啟后會繼續提交事務。通過這個機制redo log 和 binlog 的狀態始終一致。這部分如果能主動寫出「XID 被寫入 binlog用于 redo log 和 binlog 的關聯」面試官對你的底層理解會非常認可。7. SQL 優化與慢查詢排查從 explain 到索引失效SQL 優化是 Java 面試中「實戰感」最強的模塊。面試官會給你一條慢查詢日志或者直接問「線上有個 SQL 跑了 5 秒你怎么排查」7.1 開啟慢查詢日志首先要能說出慢查詢日志怎么配置。MySQL 提供了兩個關鍵參數和一條常用命令-- 查看是否開啟慢查詢及閾值 SHOW VARIABLES LIKE slow_query_log; SHOW VARIABLES LIKE long_query_time; -- 開啟慢查詢當前會話/實例生效 SET GLOBAL slow_query_log ON; SET GLOBAL long_query_time 1;需要說明的是long_query_time的單位是秒設為 1 意味著執行時間超過 1 秒的 SQL 會被記錄到慢查詢日志中。生產環境建議設為 1 或更低具體根據業務情況調整。7.2 用 explain 分析執行計劃拿到慢查詢 SQL 后第一步不是猜而是看執行計劃。explain 是 MySQL 用來展示 SQL 執行計劃的關鍵字EXPLAIN SELECT u.id, u.name, o.order_no FROM user u LEFT JOIN orders o ON u.id o.user_id WHERE u.status 1 ORDER BY u.create_time DESC;執行后重點看這幾個字段字段關鍵含義type訪問類型system const eq_ref ref range index ALL。看到 ALL 就要警惕全表掃描key實際使用的索引為 NULL 說明沒走索引rows預估掃描行數越小越好Extra出現 Using filesort 說明排序沒用索引Using temporary 說明使用了臨時表Using index 說明覆蓋索引生效常見的優化動作包括為 WHERE 條件列建立索引、為 ORDER BY 列建立索引避免 filesort、把 SELECT * 改成只查需要的列、拆分復雜 join 為多次簡單查詢。7.3 經典索引失效 SQL 示例下面這條 SQL 是在真實項目中非常容易出現的問題類型-- 錯誤示例對索引列使用函數導致索引失效 SELECT * FROM orders WHERE DATE(create_time) 2026-08-01; -- 正確示例改成范圍查詢走索引 SELECT * FROM orders WHERE create_time 2026-08-01 00:00:00 AND create_time 2026-08-02 00:00:00;另外一個高頻優化點是在深分頁場景-- 錯誤示例深分頁掃描大量數據 SELECT * FROM orders ORDER BY id LIMIT 100000, 20; -- 優化示例先通過覆蓋索引拿到起始 id再回表查完整數據 SELECT * FROM orders WHERE id (SELECT id FROM orders ORDER BY id LIMIT 100000, 1) ORDER BY id LIMIT 20;面試時能給出這兩類案例比單純說「加索引」「避免 SELECT *」要有說服力得多。8. 主從復制與高可用binlog 到中繼日志的傳遞鏈路主從復制是分布式系統面試中和 MySQL 關聯最深的一塊。Java 開發者雖然不一定要部署 MySQL 主從但必須理解讀寫分離的原理和常見問題。8.1 主從復制原理MySQL 主從復制的過程分為三個步驟主庫把數據變更記錄寫入 binlog。從庫的 I/O 線程連接主庫請求指定位置的 binlog并把收到的內容寫入從庫的中繼日志relay log。從庫的 SQL 線程讀取中繼日志在本地重放日志事件更新到自身的數據庫中。這里有一個細節需要區分從庫有一個 I/O 線程負責拉取 binlog有一個 SQL 線程負責執行中繼日志。兩個線程是異步的所以從庫數據通常比主庫有延遲這就是主從延遲問題的根源。8.2 binlog 的三種格式面試官問 binlog 格式是想考察你是否清楚主從復制在不同格式下的行為差異。Statement記錄的是 SQL 語句本身。優點是日志量小缺點是非確定性函數如 NOW()、UUID() 在主從兩端執行結果可能不同導致數據不一致。Row記錄的是每行數據的具體變更內容。優點是最精確不受函數影響缺點是日志量大。MixedMySQL 自動判斷在可能產生不一致時使用 Row否則使用 Statement。從實踐角度看目前主流推薦使用 Row 格式尤其是要求數據強一致的業務場景。8.3 主從延遲的常見原因和應對主從延遲的常見原因有從庫硬件性能不如主庫、從庫同時承擔了多份復制任務、主庫大事務導致 binlog 積壓、從庫上執行了耗時的查詢或備份任務。應對手段包括提升從庫配置、縮短主庫大事務、拆分為多個從庫分攤讀取壓力、監控 Seconds_Behind_Master 指標。對于必須實時讀到最新數據的業務可以在中間件層面做強制走主庫的策略。9. 容易被細問的細節題int(5)、utf8mb4、連接數這類題目不一定每家都問但面試官如果提到通常是在傳「你到底是真用過還是只會背概念」的信號。9.1 int(5) 到底是什么意思這是一個非常經典的前后端協作誤解。int(5)不是指「這個整數最多只能存 5 位數」。int 類型在 MySQL 中永遠占 4 個字節能存儲的范圍是 -2147483648 到 2147483647約 21 億。int(5) 中的 5 指的是顯示寬度并且只在搭配ZEROFILL時有效。比如INT(5) ZEROFILL存的值為 42查詢時會顯示 00042。如果沒有 ZEROFILLint(5) 和 int(11) 在存儲上沒有區別。9.2 utf8 和 utf8mb4 的區別MySQL 的 utf8 字符集不是真正的四字節 UTF-8它最多只支持 3 個字節無法存儲 emoji 表情和一些生僻漢字。如果業務需要存 emoji 或四字節字符必須使用 utf8mb4并在連接層也指定對應的字符集。MySQL 8.0 的默認字符集已經是 utf8mb4這是一個很大的改進。如果你還在用 MySQL 5.7建議在建庫時顯式指定CREATE DATABASE demo_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;9.3 max_connections 和連接數問題Java 項目使用連接池連接 MySQL默認連接池大小可能在 10 到 50 之間。但如果存在連接泄漏連接池會不斷申請新連接最終把數據庫的連接數打滿報Too many connections錯誤。排查思路是先看 MySQL 當前連接數和狀態SHOW STATUS LIKE Threads_connected; SHOW GLOBAL VARIABLES LIKE max_connections;查完之后定位到具體業務應用檢查連接池是否有正確的歸還連接邏輯、連接空閑超時配置是否合理。同時一個數據庫實例的連接數不是越大越好每個連接都會消耗線程和內存過大的連接數反而會拖垮數據庫。10. Java 面試 MySQL 的 3 天復習路線現在回到文章開頭的問題3 天時間怎么最高效地把 MySQL 面試準備到位我不建議你按網上的長題庫逐題刷而是按知識模塊做「原理 練習 自測」的循環。下面是一套可執行的分配方案。Day 1存儲引擎 索引上午把 InnoDB 和 MyISAM 的區別講清楚重點理解「為什么 InnoDB 用 B 樹」和「聚簇索引與回表」。下午做索引實戰建一張測試表模擬插入 10 萬條數據分別用無索引、單列索引、聯合索引執行查詢再用 explain 看執行計劃的差異。自測題InnoDB 為什么用 B 樹而不用 B 樹聯合索引 (a, b, c)WHERE b 1能不能走索引什么是回表覆蓋索引為什么能提升查詢性能LIKE %張 為什么會導致索引失效Day 2事務 鎖 日志上午整理 ACID、隔離級別、MVCC 的執行流程畫出事務讀取數據時 Read View 的判斷過程。下午研究鎖機制重點搞清楚記錄鎖、間隙鎖、臨鍵鎖的區別。晚上用 1 小時復習 redo log、undo log、binlog 的職責和兩階段提交。自測題MySQL 默認隔離級別是什么它是怎么避免幻讀的MVCC 在可重復讀級別的實現和讀已提交有什么區別Redo log 和 binlog 為什么需要兩階段提交兩個事務互相更新不同行為什么會死鎖Day 3SQL 優化 主從復制 綜合模擬上午練習慢查詢排查流程開啟慢查詢日志、造一條慢 SQL、解釋執行計劃、給出優化方案。下午復習主從復制原理、binlog 格式、主從延遲原因。晚上挑 20 道高頻 MySQL 面試題不看答案口述回答并錄音檢查自己能不能把關鍵邏輯說完整。自測題線上一條 SQL 執行了 2 秒你怎么定位和優化SHOW ENGINE INNODB STATUS 里怎么找死鎖信息主從延遲的根本原因是什么業務上如何應對你遇到過 Too many connections 嗎怎么排查這套復習路線有一個特點始終把「為什么」放在「怎么回答」前面。你可以在此基礎上結合自己的項目經驗做補充。比如你處理過一個慢 SQL就在 Day 3 的模擬面試里把它講出來你在項目里做過讀寫分離就把主從復制部分講成自己的實踐案例。11. 最后給 Java 面試者的幾點提醒MySQL 面試題再多也逃不出存儲引擎、索引、事務、鎖、日志、優化、復制這幾個核心模塊。真正拉開差距的從來不在于你背了多少道題而在于你能不能把概念串成一條邏輯鏈并且用真實場景去解釋它們。面試官問索引你不要只回答 B 樹而是可以從全表掃描的代價講到 B 樹的層數再講到聚簇索引和回表最后用 explain 舉例。面試官問事務隔離級別你不要只背四種隔離級別而是可以指出 MySQL 默認是可重復讀并解釋 InnoDB 如何通過 MVCC 和間隙鎖解決幻讀。這種回答方式會讓你的知識體系顯得非常完整。準備面試的過程中有一個容易被忽視的點不要脫離 MySQL 實際運行環境去背概念。建議你在自己電腦上裝一個 MySQL用幾萬條測試數據跟著這篇文章的示例跑一遍。親自看一次創建索引前后執行計劃的變化效果比刷 50 道題都管用。另外面試中如果被問到不熟悉的問題不要慌張。面試官更看重的是你能否用已有知識去推理。比如你忘了間隙鎖的定義你可以從「可重復讀級別要解決幻讀」出發推出 InnoDB 需要一個能阻止其他事務插入數據的鎖機制自然就能說出間隙鎖。答錯的成本很低冷場硬編的成本很高。把 MySQL 拿下Java 面試的后端基礎環節就穩了一大半。建議把本文收藏起來按照 3 天復習路線逐段消化。面試當天把索引、事務、鎖、日志這幾個核心模塊的重點在腦子里過一遍祝你少走彎路順利拿到滿意的 Offer。