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