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