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