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