每年校招季我都會(huì)接觸不少準(zhǔn)備數(shù)據(jù)庫方向筆試的同學(xué)看到最多的狀態(tài)就是簡歷上寫著“熟悉 MySQL”“了解索引優(yōu)化”一碰到數(shù)據(jù)庫管理工程師的筆試卷卻在索引、事務(wù)、鎖、備份恢復(fù)這些題目上翻車。網(wǎng)易這套 2018 校園招聘數(shù)據(jù)庫管理工程師筆試卷出的題其實(shí)很有代表性它不一定考你背了多少概念而是考你有沒有一個(gè) DBA 的腦子數(shù)據(jù)出問題的時(shí)候你能不能快速定位、能不能給出可落地的恢復(fù)方案、能不能看懂一條 SQL 為什么會(huì)慢。這篇文章我不打算逐題報(bào)答案而是把這份試卷背后真正想篩的能力拆開配合典型題目場景和實(shí)操思路給準(zhǔn)備走數(shù)據(jù)庫管理方向的同學(xué)一份有參考價(jià)值的備考地圖。1. 一份數(shù)據(jù)庫管理工程師筆試卷到底在篩什么人1.1 寫 SQL 的人和管理數(shù)據(jù)庫的人完全是兩種物種先想清楚一個(gè)前提數(shù)據(jù)庫管理工程師不是讓你來寫業(yè)務(wù) SQL 的。業(yè)務(wù)開發(fā)也會(huì)寫 SQL但開發(fā)關(guān)心的是“這條查詢結(jié)果對(duì)不對(duì)”DBA 關(guān)心的是“這條查詢在生產(chǎn)環(huán)境會(huì)不會(huì)把庫拖垮”。這兩個(gè)視角完全不同筆試卷出題的時(shí)候也會(huì)刻意區(qū)分。比如同樣面對(duì)一張訂單表開發(fā)可能會(huì)寫SELECT * FROM orders WHERE user_id 123能跑出結(jié)果就完事。但 DBA 看到這條語句腦子里會(huì)立刻彈出幾個(gè)問題user_id 上有沒有索引type 是不是 ALLrows 掃描了多少行Extra 里有沒有 Using filesort如果這張表有幾百萬行這條語句會(huì)不會(huì)把 buffer pool 打穿有沒有可能用覆蓋索引減少回表所以你會(huì)發(fā)現(xiàn)校招筆試卷里很多題目表面上是考 SQL 語法實(shí)際考的是你有沒有這種“性能敏感”和“故障敏感”的意識(shí)。你不需要有幾年生產(chǎn)經(jīng)驗(yàn)才能答題但你需要知道一個(gè) DBA 看到問題時(shí)的思考路徑是什么。1.2 從考點(diǎn)分布反推崗位能力模型雖然這份試卷具體題目每年的版本會(huì)有調(diào)整但知識(shí)板塊的分布是有規(guī)律的。我根據(jù)帶過的校招生和這些年看到的真題大致整理出下面這張能力地圖知識(shí)板塊考察目的典型題型SQL 基礎(chǔ)與數(shù)據(jù)模型基本功是否扎實(shí)手寫 SQL、范式判斷、表設(shè)計(jì)索引與查詢優(yōu)化有沒有性能意識(shí)復(fù)合索引選擇、執(zhí)行計(jì)劃分析事務(wù)與鎖機(jī)制并發(fā)控制的理解深度隔離級(jí)別、死鎖場景分析備份恢復(fù)數(shù)據(jù)安全意識(shí)誤刪數(shù)據(jù)恢復(fù)方案設(shè)計(jì)高可用與架構(gòu)視野是否局限在單機(jī)主從復(fù)制、容災(zāi)方案操作系統(tǒng)與網(wǎng)絡(luò)基礎(chǔ)排障能力下限端口、進(jìn)程、磁盤 IO 相關(guān)題這里面有個(gè)容易被忽略的點(diǎn)數(shù)據(jù)庫管理工程師的筆試卷不只是考數(shù)據(jù)庫本身。操作系統(tǒng)、網(wǎng)絡(luò)、存儲(chǔ)這些周邊知識(shí)也會(huì)占一定比例。原因很簡單生產(chǎn)環(huán)境里數(shù)據(jù)庫出了問題排查鏈路往往是從操作系統(tǒng)開始的。比如磁盤滿了導(dǎo)致 MySQL 只讀、網(wǎng)絡(luò)抖動(dòng)導(dǎo)致主從延遲、內(nèi)存不足觸發(fā) OOM 導(dǎo)致實(shí)例重啟。筆試考這些不是為了難為你而是為了確認(rèn)你有沒有能力在“數(shù)據(jù)庫之外”找原因。1.3 2018 年這個(gè)時(shí)間點(diǎn)的特殊技術(shù)背景為什么要單獨(dú)說年份因?yàn)樾Ｕ泄P試卷的考點(diǎn)其實(shí)緊跟當(dāng)時(shí)的技術(shù)潮流。2018 年這個(gè)時(shí)間點(diǎn)有幾個(gè)特點(diǎn)MySQL 5.7 是主流生產(chǎn)版本8.0 剛發(fā)布還沒大規(guī)模鋪開所以試卷里大量題目圍繞 5.7 的行為展開比如半同步復(fù)制、GROUP BY 的排序邏輯、JSON 類型的支持。云數(shù)據(jù)庫 RDS 開始普及但很多互聯(lián)網(wǎng)公司核心庫還是自建機(jī)房物理機(jī)所以傳統(tǒng) DBA 的硬核技能——mysqldump、xtrabackup、binlog 恢復(fù)、主從切換——依然是筆試重點(diǎn)。分庫分表和分布式數(shù)據(jù)庫概念開始熱門但實(shí)際落地方案還不像今天這么成熟所以試卷里更多是考“水平拆分和垂直拆分的取舍”這類思維題很少考具體中間件操作。理解這個(gè)背景有什么用它能幫你判斷筆試著重復(fù)習(xí)的重點(diǎn)應(yīng)該放在“單機(jī)數(shù)據(jù)庫的原理和運(yùn)維”而不是上來就研究分布式數(shù)據(jù)庫。很多同學(xué)看了一堆 TiDB、OceanBase 的資料結(jié)果基礎(chǔ)題反而丟分這個(gè)方向就偏了。2. 索引與執(zhí)行計(jì)劃為什么這部分永遠(yuǎn)是大頭2.1 最左前綴原則一道送分題怎么變成送命題索引類題目幾乎是數(shù)據(jù)庫筆試試卷里雷打不動(dòng)的第一大戶。其中最高頻的考點(diǎn)就是復(fù)合索引的最左前綴原則。很多同學(xué)覺得這個(gè)簡單但實(shí)際做題時(shí)換一個(gè)問法就懵。舉一個(gè)典型題例表上有復(fù)合索引(a, b, c)下面幾個(gè)查詢哪些能用到索引WHERE a 1 AND b 2 AND c 3——全命中最理想。WHERE b 2 AND c 3——用不到因?yàn)闆]有從最左列開始。WHERE a 1 AND c 3——只能用a這一列c沒法用索引過濾。WHERE a IN (1, 2) AND b 10 AND c 3——能用a和b的范圍條件但c還是會(huì)失效。第 4 個(gè)例子是最容易答錯(cuò)的。原因是 B 樹索引的匹配順序是有方向的范圍查詢之后后續(xù)列無法繼續(xù)用于精確定位。b 10一旦成為范圍條件c就失去了參與索引匹配的機(jī)會(huì)。這就是很多人背了“最左前綴”四個(gè)字卻沒法解釋“為什么會(huì)這樣”的地方。另外一個(gè)容易被忽略的考點(diǎn)是排序。復(fù)合索引(a, b)不僅能加速WHERE a ?的查詢還能讓ORDER BY a, b直接走索引避免 filesort。筆試卷經(jīng)常會(huì)問“下面這條語句能否避免 Using filesort”你只要記住索引列的順序和排序方向一致才行ORDER BY a DESC, b ASC這種混著來的情況優(yōu)化器往往做不到完美利用索引。2.2 執(zhí)行計(jì)劃的關(guān)鍵指標(biāo)別把 explain 的結(jié)果當(dāng)擺設(shè)如果說索引概念題是第一層那執(zhí)行計(jì)劃分析就是第二層。筆試不會(huì)讓你真跑一條 SQL但它會(huì)給你一條 SQL 外加一個(gè) explain 輸出讓你判斷問題出在哪。這種題核心看四個(gè)字段type訪問類型從好到差大致是const→eq_ref→ref→range→index→ALL。如果看到ALL意味著全表掃描這類 SQL 在生產(chǎn)環(huán)境基本會(huì)被 DBA 重點(diǎn)盯上。key實(shí)際用到的索引是哪個(gè)。如果為NULL說明沒用到索引。rows預(yù)估掃描行數(shù)。這個(gè)數(shù)字越接近表的總行數(shù)問題越嚴(yán)重。Extra出現(xiàn)Using filesort或Using temporary是危險(xiǎn)信號(hào)意味著查詢需要額外的排序或臨時(shí)表性能很難好。我見過最典型的題目是給出SELECT * FROM user WHERE age 20 ORDER BY create_time以及一個(gè)顯示Using filesort的 explain 結(jié)果問怎么優(yōu)化。這里有兩個(gè)維度可以考慮如果age區(qū)分度不高加索引未必有顯著收益但如果查詢本身低頻可以先建立(age, create_time)的復(fù)合索引讓過濾和排序都能走索引。如果查詢高頻還可以考慮在create_time上單獨(dú)建索引先排好序再回表過濾也行具體看統(tǒng)計(jì)信息。筆試面試?yán)镂乙话憬ㄗh你按這個(gè)路徑答先做數(shù)據(jù)量級(jí)和業(yè)務(wù)頻率的判斷再給索引方案最后補(bǔ)充一句“上線前要在測試環(huán)境用真實(shí)數(shù)據(jù)量驗(yàn)證”。這樣答出來比一上來就丟一個(gè)“加索引”的結(jié)論要專業(yè)得多。2.3 覆蓋索引和索引下推能拉開差距的細(xì)節(jié)如果試卷有拔高題往往會(huì)從覆蓋索引和索引下推這兩個(gè)點(diǎn)出。覆蓋索引意思是查詢的所有列都在索引里不需要回表。舉個(gè)例子表上有索引(user_id, status)查詢SELECT status FROM order WHERE user_id 123因?yàn)閡ser_id和status都在這顆索引樹上直接遍歷索引就能拿到結(jié)果省掉了一次主鍵回表。筆試?yán)飭枴斑@條 SQL 為什么快”往往就是覆蓋索引的功勞。索引下推Index Condition PushdownICP是 MySQL 5.6 引入的優(yōu)化很多人沒聽說過。它的邏輯是在沒有 ICP 之前存儲(chǔ)引擎從索引中取出記錄后要回表拿到完整行再由 Server 層判斷其他條件有了 ICP可以在存儲(chǔ)引擎層先把一部分條件過濾掉減少回表次數(shù)。舉個(gè)經(jīng)典例子復(fù)合索引(zipcode, lastname)查詢WHERE zipcode 100000 AND lastname LIKE %張%。lastname LIKE %張%無法用索引匹配但 ICP 可以在讀取索引記錄時(shí)就用 LIKE 條件過濾掉大量無效數(shù)據(jù)再回表。筆試如果問你“ICP 有什么好處”核心答案就是減少回表次數(shù)降低 IO。能把這個(gè)細(xì)節(jié)寫出來基本就能在眾多候選人里拉開差距。3. 事務(wù)隔離級(jí)別與鎖機(jī)制這類題怎么答才不丟分3.1 隔離級(jí)別背得下來但題還是不會(huì)做事務(wù)隔離級(jí)別這塊面試筆試幾乎是必考。但我發(fā)現(xiàn)一個(gè)普遍問題很多同學(xué)四句話背得滾瓜爛熟——讀未提交有臟讀讀已提交解決臟讀但會(huì)不可重復(fù)讀可重復(fù)讀解決不可重復(fù)讀但可能幻讀串行化最安全但性能差——可真給一個(gè)場景題就不知道怎么用了。原因在于沒有理解每個(gè)隔離級(jí)別是“在性能和一致性之間做了哪種取舍”。更關(guān)鍵的是很多同學(xué)不知道 MySQL 的默認(rèn)隔離級(jí)別是可重復(fù)讀Repeatable Read而 Oracle、PostgreSQL 默認(rèn)是讀已提交Read Committed。這個(gè)差異在筆試?yán)锝?jīng)常出現(xiàn)而且會(huì)直接影響后續(xù)鎖機(jī)制和 MVCC 的答案。舉個(gè)典型場景題事務(wù) A 先讀取了一行balance 100事務(wù) B 修改這行變成 200并提交。請(qǐng)問在 RR 和 RC 下事務(wù) A 再次讀取這行分別看到什么RR 下因?yàn)榭煺兆x機(jī)制A 看到還是 100RC 下因?yàn)槊看巫x都拿最新已提交版本A 會(huì)看到 200。這種題不需要背概念理解 MVCC 的多版本鏈就能答對(duì)。MVCC 是 MySQL InnoDB 實(shí)現(xiàn)隔離級(jí)別的核心機(jī)制筆試高頻考點(diǎn)。它維護(hù)了一條版本鏈每行記錄有多版本數(shù)據(jù)read view決定了事務(wù)能看到哪個(gè)版本。RR 下read view在第一次查詢時(shí)生成整個(gè)事務(wù)復(fù)用RC 下每次查詢都重新生成。所以 RR 下同樣的查詢得到一致的結(jié)果這就是快照讀層面的“一致性讀”。3.2 行鎖、間隙鎖、next-key lock 的典型場景MVCC 解決了快照讀的隔離問題但更新操作是“當(dāng)前讀”需要真正的鎖。這就引出了行鎖、間隙鎖、next-key lock 這些考點(diǎn)。很多校招生對(duì)鎖的理解停留在“讀鎖和寫鎖”這個(gè)層面一旦筆試問到 InnoDB 的具體鎖類別就亂了。這里需要清楚幾個(gè)層次共享鎖S 鎖和排他鎖X 鎖最基礎(chǔ)的鎖類型一行記錄可以被多個(gè)事務(wù)加 S 鎖但 X 鎖只能被一個(gè)事務(wù)持有。記錄鎖Record Lock鎖住的是索引記錄本身注意 InnoDB 是通過索引來鎖行的不是直接鎖物理行。間隙鎖Gap Lock鎖住索引記錄之間的間隙防止其他事務(wù)在這個(gè)間隙插入新的記錄用來解決幻讀。Next-key Lock記錄鎖 間隙鎖的組合鎖住的范圍是一個(gè)左開右閉區(qū)間(前一條記錄, 當(dāng)前記錄]。典型筆試場景在 RR 隔離級(jí)別下數(shù)據(jù)庫有 id 為 1、5、10 三行事務(wù) A 執(zhí)行SELECT * FROM t WHERE id 5 FOR UPDATE。這個(gè)語句會(huì)鎖住id 5的記錄行嗎還會(huì)不會(huì)鎖住(5, 10]和(10, ∞)的間隙答案是它會(huì)鎖住 id10 這一行同時(shí)因?yàn)?RR 下默認(rèn)用 next-key lock間隙(5, 10)和(10, 正無窮)也會(huì)被鎖其他事務(wù)想插入 id8 或 id100 都會(huì)被阻塞。很多人不理解為什么“查不到的行”還要加鎖。這就是 RR 隔離級(jí)別為了防幻讀付出的代價(jià)。如果筆試題目問“數(shù)據(jù)庫默認(rèn)隔離級(jí)別下間隙鎖會(huì)帶來什么副作用”你可以答降低并發(fā)插入能力容易引發(fā)死鎖這也是很多互聯(lián)網(wǎng)公司把隔離級(jí)別從 RR 改成 RC 的原因之一因?yàn)?RC 下只存在記錄鎖間隙鎖被禁用了死鎖概率會(huì)明顯下降。3.3 死鎖分析題怎么把排查思路寫到卷子上死鎖是 DBA 工作中必須面對(duì)的問題筆試卷盡量不會(huì)出太復(fù)雜但一定會(huì)出一個(gè)典型場景兩個(gè)事務(wù)各自持有一個(gè)鎖又同時(shí)等待對(duì)方持有的鎖。最常見的就是兩條 UPDATE 語句順序相反。事務(wù) A 先更新 id1 再更新 id2事務(wù) B 先更新 id2 再更新 id1。當(dāng)兩個(gè)事務(wù)并發(fā)執(zhí)行時(shí)A 持有 id1 的鎖在等 id2B 持有 id2 的鎖在等 id1互相不肯放手InnoDB 檢測到死鎖后會(huì)選擇回滾一個(gè)代價(jià)較小的事務(wù)。筆試遇到這種題答題的關(guān)鍵不是把死鎖定義默寫一遍而是給出一個(gè)完整的分析鏈條兩個(gè)事務(wù)各自持有什么鎖、正在等什么鎖畫一個(gè)等待環(huán)出來。如何從SHOW ENGINE INNODB STATUS的日志里發(fā)現(xiàn)死鎖信息看LATEST DETECTED DEADLOCK部分。往業(yè)務(wù)層面怎么修統(tǒng)一 UPDATE 語句里條件的順序保證所有事務(wù)按相同順序訪問行或者縮短事務(wù)持續(xù)時(shí)間減少鎖持有的窗口。如果業(yè)務(wù)確實(shí)沒法調(diào)整順序可以在高峰期前通過SELECT ... FOR UPDATE預(yù)鎖定目標(biāo)行或者考慮降低隔離級(jí)別到 RC減少間隙鎖帶來的死鎖可能性。這套答法能體現(xiàn)出你不是在背概念而是真的想過“如果我來值班我會(huì)怎么處理”。還有一個(gè)小細(xì)節(jié)在描述死鎖時(shí)一定要提到 InnoDB 會(huì)通過檢測機(jī)制而不是超時(shí)機(jī)制來處理大部分死鎖死鎖檢測默認(rèn)開啟并且會(huì)把回滾代價(jià)較小的事務(wù)選為 victim。這個(gè)細(xì)節(jié)能加分。4. SQL 優(yōu)化與慢查詢排查筆試題背后的運(yùn)維思維4.1 一道 SQL 優(yōu)化題考察的其實(shí)是排查順序數(shù)據(jù)庫管理工程師崗位筆試基本不會(huì)繞過 SQL 優(yōu)化這塊。但這類題目并不單純考“你會(huì)不會(huì)寫高效 SQL”而是考你看到一個(gè)慢 SQL 之后腦子里有沒有一條標(biāo)準(zhǔn)的排查鏈路。我建議所有準(zhǔn)備筆試的同學(xué)把一個(gè)思路印在腦海里慢 SQL 出現(xiàn)后第一步永遠(yuǎn)是確認(rèn)問題現(xiàn)象而不是急著改 SQL。比如這條 SQL 是偶發(fā)慢還是持續(xù)慢慢的時(shí)候系統(tǒng)整體負(fù)載如何有沒有其他大查詢并行表數(shù)據(jù)量最近有沒有突增執(zhí)行計(jì)劃有沒有變化是不是統(tǒng)計(jì)信息不準(zhǔn)確導(dǎo)致走了錯(cuò)誤索引很多校招生一看到慢 SQL 就回答“加索引”這是最典型的扣分項(xiàng)。真實(shí)生產(chǎn)環(huán)境里一條 SQL 變慢的原因可能很多統(tǒng)計(jì)信息過期導(dǎo)致執(zhí)行計(jì)劃偏離、鎖競爭導(dǎo)致阻塞、磁盤 IO 抖動(dòng)、查詢緩存失效、或者網(wǎng)絡(luò)延遲。不加判斷直接加索引往往解決不了實(shí)際問題。如果筆試卷給的具體場景是“訂單表 order 有 500 萬行查詢SELECT * FROM order WHERE user_id 123 ORDER BY create_time DESC LIMIT 20很慢怎么優(yōu)化”我會(huì)這么拆解先看user_id是否有索引。如果沒有全表掃描是必然的首選是加(user_id, create_time)復(fù)合索引讓過濾和排序同時(shí)走索引。如果已經(jīng)有索引但還慢看查詢是否用到了回表。SELECT *意味著查詢所有列即使索引命中也得回表拿數(shù)據(jù)?？紤]改成覆蓋索引只返回必要字段減少回表次數(shù)。如果業(yè)務(wù)允許考慮把LIMIT 20變成一個(gè)基于游標(biāo)的翻頁方式避免深分頁問題比如用WHERE create_time 上次查詢的最后一條時(shí)間來替代OFFSET。這種回答順序展示的是“定位問題 → 分析原因 → 給方案 → 預(yù)估效果”的完整閉環(huán)比單純丟一個(gè)方案扎實(shí)很多。4.2 慢查詢?nèi)罩九c工具鏈筆試怎么考慢查詢?nèi)罩臼?DBA 定位慢 SQL 的第一手?jǐn)?shù)據(jù)。筆試卷可能不會(huì)直接考命令參數(shù)但會(huì)給你一個(gè)場景某天業(yè)務(wù)方反饋線上接口變慢你要怎么找出慢 SQL。我的建議是把以下概念理清slow_query_log開啟開關(guān)long_query_time閾值。生產(chǎn)環(huán)境一般設(shè) 1 秒如果實(shí)例壓力大可以調(diào)到 2 秒或 5 秒避免日志刷太多。log_queries_not_using_indexes可以記錄沒走索引的查詢這在筆試?yán)锟梢宰鳛橐粋€(gè)補(bǔ)充點(diǎn)提出來說明你有“提前發(fā)現(xiàn)隱患”的意識(shí)。日志拿到后可以用mysqldumpslow或pt-query-digest做聚合分析按執(zhí)行時(shí)間、掃描行數(shù)排序篩選出真正需要處理的頭部 SQL。筆試考這個(gè)點(diǎn)的意圖是看你有沒有“從海量日志里找到關(guān)鍵問題”的思路?；卮饡r(shí)不需要很細(xì)節(jié)地背出每個(gè)參數(shù)但一定要能說清楚“誰的日志、怎么開啟、達(dá)到什么閾值、如何分析”這樣邏輯就完整了。4.3 分庫分表概念題背后的架構(gòu)思維2018 年前后的筆試分庫分表開始頻繁出現(xiàn)。這類題目通常是概念題加一點(diǎn)設(shè)計(jì)題。比如單表數(shù)據(jù)量到了幾千萬寫性能下降要不要分庫分表怎么分這里有一個(gè)很關(guān)鍵的判斷分庫分表是最后手段不是第一選擇。筆試卷里如果考這個(gè)正確答案的第一步往往是先排除其他可能性歸檔歷史數(shù)據(jù)、優(yōu)化索引、升級(jí)硬件、讀寫分離。很多同學(xué)上來就說“按 user_id 分 64 張表”忽略了業(yè)務(wù)場景反而暴露了“沒有真實(shí)運(yùn)維經(jīng)驗(yàn)”的問題。如果確實(shí)要分需要說清楚兩個(gè)方向水平拆分同一張表的數(shù)據(jù)按照某個(gè)分片鍵拆到多張表。比如訂單表按order_id哈希分片每個(gè)分片存不同范圍的數(shù)據(jù)。優(yōu)點(diǎn)是水平擴(kuò)展能力強(qiáng)缺點(diǎn)是跨分片的 JOIN、聚合、事務(wù)會(huì)變得復(fù)雜。垂直拆分把不同的業(yè)務(wù)列拆到不同的表或庫里。比如把熱點(diǎn)字段和非熱點(diǎn)字段分開。優(yōu)點(diǎn)是單表變瘦、緩存命中率提高缺點(diǎn)是拆分后查詢邏輯變復(fù)雜。答這種題的時(shí)候如果能順帶提一句“分片鍵的選擇特別重要要盡量讓查詢帶上分片鍵避免跨分片掃描”會(huì)顯得你有落地思考。因?yàn)檎鎸?shí)場景里分片鍵選錯(cuò)會(huì)導(dǎo)致大量廣播查詢性能比不分片還差。5. 備份恢復(fù)與高可用筆試?yán)锲凹軜?gòu)”的題目怎么切入5.1 從“誤刪數(shù)據(jù)”場景看備份恢復(fù)能力數(shù)據(jù)庫管理工程師和開發(fā)工程師最大的區(qū)別就是你對(duì)“數(shù)據(jù)沒了”這件事有多敏感。筆試卷里大概率會(huì)出一道備份恢復(fù)的題最常見的場景是某天凌晨三點(diǎn)一個(gè)同事執(zhí)行了一條DELETE或者DROP TABLE誤刪了核心表數(shù)據(jù)你作為 DBA怎么處理這道題沒有標(biāo)準(zhǔn)答案但有一條比較完整的思路線先冷靜別讓問題擴(kuò)大。如果誤刪是剛發(fā)生的立刻檢查 binlog 是否開啟。MySQL 生產(chǎn)環(huán)境一般都會(huì)開啟log_bin如果開啟了恢復(fù)就有戲。確認(rèn)全量備份的情況。上次全備是什么時(shí)候用mysqldump還是xtrabackup如果全備存在可以起一個(gè)臨時(shí)實(shí)例把全備恢復(fù)到誤刪前一秒的狀態(tài)。用 binlog 做增量追加。全備恢復(fù)到某個(gè)時(shí)間點(diǎn)之后把誤刪時(shí)刻之前的 binlog 重放到臨時(shí)實(shí)例利用mysqlbinlog --stop-datetime或者--stop-position精確截?cái)唷Ｗ詈笤侔雅R時(shí)實(shí)例里的這部分?jǐn)?shù)據(jù)導(dǎo)回生產(chǎn)庫。這個(gè)流程里有幾個(gè)筆試高頻坑點(diǎn)一定要提“先停止業(yè)務(wù)寫入或者把表置為只讀”防止后續(xù)新的寫入污染 binlog 的恢復(fù)位點(diǎn)。一定要提“恢復(fù)到臨時(shí)實(shí)例而不是直接在生產(chǎn)庫操作”先驗(yàn)證數(shù)據(jù)完整性再導(dǎo)入生產(chǎn)。一定要提“恢復(fù)完成后驗(yàn)證數(shù)據(jù)的行數(shù)和關(guān)鍵業(yè)務(wù)指標(biāo)”不能恢復(fù)到一半看沒報(bào)錯(cuò)就認(rèn)為完了。如果能再補(bǔ)充一句“如果表被 DROP還需要注意表結(jié)構(gòu)是否保留比如從全備中單獨(dú)恢復(fù)表結(jié)構(gòu)”就更能體現(xiàn)細(xì)節(jié)。這類題的核心在于展示你有條不紊的故障應(yīng)對(duì)能力而不是背一條命令。5.2 RPO 和 RTO兩個(gè)經(jīng)常被忽略的基礎(chǔ)概念備份恢復(fù)板塊里有兩個(gè)概念筆試很容易出RPORecovery Point Objective恢復(fù)點(diǎn)目標(biāo)和 RTORecovery Time Objective恢復(fù)時(shí)間目標(biāo)。這兩個(gè)概念很多同學(xué)在簡歷上寫過但做題時(shí)經(jīng)常搞混。RPO 指的是“數(shù)據(jù)最多丟多少”衡量的是數(shù)據(jù)丟失的容忍度。RPO 0 代表不允許丟任何數(shù)據(jù)必須做實(shí)時(shí)同步。RTO 指的是“恢復(fù)要多快”衡量的是業(yè)務(wù)中斷的容忍度。RTO 越短代表業(yè)務(wù)中斷時(shí)間要求越嚴(yán)。筆試經(jīng)常會(huì)用業(yè)務(wù)化的語言來描述比如“在線支付系統(tǒng)的數(shù)據(jù)庫不允許丟失任何一筆交易記錄”這可翻譯成 RPO ≈ 0“核心交易庫要求 30 分鐘內(nèi)恢復(fù)可用”這描述的就是 RTO ≤ 30 分鐘。這兩個(gè)概念有什么用它們可以幫你反推備份方案。RPO 要求高就必須讓 binlog 實(shí)時(shí)同步到異地或者用半同步復(fù)制RTO 要求高就得準(zhǔn)備預(yù)熱的備庫或者完善的自動(dòng)化切換工具而不能只靠從磁帶恢復(fù)。答備份類題目時(shí)先用 RPO/RTO 把目標(biāo)定義清楚再給方案會(huì)顯得非常專業(yè)。5.3 主從復(fù)制與高可用方案原理比工具更重要高可用這塊筆試卷的考察重點(diǎn)一般不是“你會(huì)不會(huì)搭 MHA”而是“你有沒有理解主從復(fù)制的原理”。因?yàn)榫唧w的工具會(huì)過時(shí)但核心原理是穩(wěn)定的。MySQL 主從復(fù)制的基本流程要能說清楚主庫的變更寫入 binlog。備庫的 IO 線程去主庫拉取 binlog寫入中繼日志relay log。備庫的 SQL 線程讀取 relay log 并執(zhí)行把變更應(yīng)用到備庫。復(fù)制相關(guān)的題目有兩個(gè)非常經(jīng)典的坑一個(gè)是“主從延遲”。備庫回放 binlog 的速度跟不上主庫寫入速度導(dǎo)致備庫數(shù)據(jù)落后。筆試如果問“主從延遲怎么解決”可以答優(yōu)先檢查備庫磁盤 IO 是否瓶頸、是否單線程回放導(dǎo)致速度上不去5.6 之后可以并行復(fù)制、大事務(wù)是否拖慢回放進(jìn)度必要時(shí)考慮讀寫分離把實(shí)時(shí)性要求高的讀流量打到主庫。另一個(gè)是“半同步復(fù)制與異步復(fù)制的取舍”。異步復(fù)制下主庫提交事務(wù)不等待備庫確認(rèn)性能好但主庫宕機(jī)可能丟數(shù)據(jù)半同步復(fù)制要求至少一個(gè)備庫收到 binlog 并寫入 relay log 后才返回提交成功RPO 更可控但性能損耗更大。筆試的時(shí)候如果能主動(dòng)把“業(yè)務(wù)允許丟多少數(shù)據(jù)”和“主庫能承受多大的性能損耗”這兩個(gè)維度結(jié)合回答會(huì)顯得很有高度。工具層面的 MHA、Orchestrator 可以作為選學(xué)內(nèi)容提一嘴2018 年 MHA 還是很主流的但如果考生能說出“它是基于主從復(fù)制做故障轉(zhuǎn)移本質(zhì)是腳本化操作”已經(jīng)比大多數(shù)人強(qiáng)了。6. 從一份筆試卷反推完整備考地圖6.1 知識(shí)點(diǎn)優(yōu)先級(jí)別把時(shí)間浪費(fèi)在低頻考點(diǎn)上校招備考時(shí)間有限不可能面面俱到。根據(jù)這份試卷的考察傾向我建議按優(yōu)先級(jí)去投入優(yōu)先級(jí)知識(shí)點(diǎn)建議投入第一梯隊(duì)SQL 基礎(chǔ)、索引原理、執(zhí)行計(jì)劃、事務(wù)隔離級(jí)別必須拿到高分這是筆試的基本盤第二梯隊(duì)鎖機(jī)制、死鎖分析、備份恢復(fù)、主從復(fù)制區(qū)分度所在決定能不能進(jìn)面試第三梯隊(duì)參數(shù)調(diào)優(yōu)、內(nèi)核原理、分布式數(shù)據(jù)庫、NoSQL有能力再深入通常占分不多第一梯隊(duì)為什么必須是 SQL 和索引因?yàn)檫@是幾乎所有數(shù)據(jù)庫相關(guān)崗位的共同要求平臺(tái)、業(yè)務(wù)、數(shù)據(jù)庫種類都可能換但索引和事務(wù)的原理是不變的。第二梯隊(duì)是 DBA 崗位的區(qū)分項(xiàng)開發(fā)崗不太會(huì)考主從復(fù)制和備份恢復(fù)所以這套題能篩出真正想做數(shù)據(jù)庫管理的人。第三梯隊(duì)不用花太多時(shí)間但如果你已經(jīng)在第二梯隊(duì)很扎實(shí)了適當(dāng)看一些存儲(chǔ)引擎源碼分析或者分布式事務(wù)的內(nèi)容在面試環(huán)節(jié)會(huì)是很好的亮點(diǎn)。6.2 實(shí)操練習(xí)路徑本地搭一套環(huán)境自己折騰一遍筆試準(zhǔn)備不能只看題最好把動(dòng)手驗(yàn)證的習(xí)慣養(yǎng)成。準(zhǔn)備校招期間我比較推薦做一個(gè)最小化實(shí)驗(yàn)環(huán)境一臺(tái)普通電腦裝一個(gè) MySQL 5.7或者直接裝 MySQL 8.0把下面這幾個(gè)實(shí)驗(yàn)過一遍創(chuàng)建一張十萬行的測試表分別在有索引和沒索引的情況下執(zhí)行同樣的 WHERE 查詢觀察執(zhí)行時(shí)間和 explain 輸出差異。用兩個(gè)終端模擬兩個(gè)事務(wù)分別設(shè)置不同隔離級(jí)別觀察隔離級(jí)別對(duì)讀一致性的影響。手動(dòng)執(zhí)行UPDATE和SELECT ... FOR UPDATE制造一個(gè)死鎖然后查SHOW ENGINE INNODB STATUS看死鎖日志長什么樣。開啟slow_query_log故意寫一條不帶索引的查詢看慢查詢?nèi)罩臼欠裼涗洝Ｗ鲆淮稳總浞萑缓笥?binlog 恢復(fù)到誤刪前時(shí)間點(diǎn)整個(gè)過程走一遍。這個(gè)過程能幫你把紙面知識(shí)變成肌肉記憶。特別是備份恢復(fù)如果不親手做一次考場上遇到“誤刪恢復(fù)”的題只能靠想象很難答出細(xì)節(jié)。而只要你做過一次哪怕只恢復(fù)了一百行數(shù)據(jù)那道題你也能給出特別具體的步驟。6.3 筆試之外的隱性加分項(xiàng)怎么在面試時(shí)接住追問筆試過了還有面試面試官很多時(shí)候會(huì)在簡歷里找“亮點(diǎn)”。我建議在準(zhǔn)備筆試的同時(shí)有意識(shí)地積累幾個(gè)可以講的經(jīng)歷。故障復(fù)盤不管是在實(shí)習(xí)還是自己的實(shí)驗(yàn)環(huán)境里遇到的任何數(shù)據(jù)庫問題只要你能講清楚現(xiàn)象、排查過程、根因、解決方案這就是一個(gè)好素材。哪怕是一次本地環(huán)境死鎖只要復(fù)盤邏輯完整也很有說服力。工具使用percona-toolkit里的pt-query-digest、pt-online-schema-change如果你用過其中任意一個(gè)并能解釋“它在線改表是怎么減少鎖阻塞的”很容易打動(dòng)面試官。版本特性關(guān)注MySQL 8.0 的窗口函數(shù)、CTE、降序索引、不可見索引等新特性筆試未必考但如果面試時(shí)能主動(dòng)提出來并結(jié)合自己實(shí)驗(yàn)環(huán)境里的驗(yàn)證結(jié)果會(huì)讓人覺得你有持續(xù)學(xué)習(xí)的習(xí)慣。這些內(nèi)容不是短期能突擊出來的但如果你現(xiàn)在離校招還有一段時(shí)間完全可以按這個(gè)方向積累。說實(shí)話我自己帶過的實(shí)習(xí)生里最后拿到數(shù)據(jù)庫管理工程師 offer 的往往不是最會(huì)背題目的人而是能在一兩個(gè)點(diǎn)上講出自己真實(shí)思考和驗(yàn)證的人。最后再分享一個(gè)我做錯(cuò)題筆記的小習(xí)慣。不要在紙上抄概念而是用“場景 → 原理 → 解決路徑”三段式來記錄。比如遇到一道死鎖題我會(huì)寫場景是兩條 UPDATE 順序不一致并發(fā)執(zhí)行原理是 InnoDB 的行鎖和等待環(huán)解決路徑是統(tǒng)一事務(wù)內(nèi)語句順序、縮小事務(wù)跨度、必要時(shí)調(diào)整隔離級(jí)別。每道錯(cuò)題都按這個(gè)模板過一遍比單純背概念高效得多。這份 2018 年筆試卷真正有價(jià)值的不是那幾十分而是它幫你把“數(shù)據(jù)庫管理工程師”這個(gè)崗位的輪廓描清楚了照著這個(gè)輪廓去補(bǔ)知識(shí)方向基本不會(huì)跑偏。