易校招數(shù)據(jù)庫管理工程師筆試備考：SQL、事務(wù)與索引優(yōu)化全攻略)
網(wǎng)易2023校招提前批放出的數(shù)據(jù)庫管理工程師杭研崗位筆試到底考什么、怎么準備是很多準備校招的同學(xué)最關(guān)心的問題。我前后參與過不少校招出題和評審工作也幫團隊篩過大量簡歷可以負責任地說數(shù)據(jù)庫管理工程師的筆試和開發(fā)崗是兩條完全不同的線算法題不是主角真正拉開差距的是數(shù)據(jù)庫原理、SQL基本功、事務(wù)與鎖、索引與性能優(yōu)化、高可用與日常運維這些硬核模塊。這篇文章不涉及任何具體真題保密范圍內(nèi)我也拿不到而是按崗位的普遍考察規(guī)律整理出一條可落地的備考主線。它適合正在準備網(wǎng)易校招的同學(xué)也適合所有想往數(shù)據(jù)庫方向走的求職者參考。1. 崗位畫像與筆試考察邏輯1.1 數(shù)據(jù)庫管理工程師在杭研做什么數(shù)據(jù)庫管理工程師這個崗位在校招里經(jīng)常被誤解成“高級DBA”。實際上杭研這類互聯(lián)網(wǎng)公司的數(shù)據(jù)庫管理工程師職責范圍比傳統(tǒng)DBA更寬既要管數(shù)據(jù)庫的日常穩(wěn)定運行也要參與業(yè)務(wù)側(cè)的數(shù)據(jù)庫設(shè)計、SQL審核、慢查詢治理、容量規(guī)劃還會涉及數(shù)據(jù)同步、備份恢復(fù)、高可用架構(gòu)的落地。說白了這個崗位要的是“能聽懂業(yè)務(wù)也能搞定數(shù)據(jù)庫底層”的人。這和后端開發(fā)崗位的最大區(qū)別在于后端開發(fā)寫業(yè)務(wù)邏輯數(shù)據(jù)庫管理工程師是在“伺候”支撐業(yè)務(wù)的數(shù)據(jù)底座。筆試也因此不會考太多算法題反而更看重對數(shù)據(jù)庫內(nèi)核機制的理解深度和工程手感。理解了這一點你就能明白為什么筆試的重點是那些“看似基礎(chǔ)、實則能拉開差距”的數(shù)據(jù)庫知識點。1.2 提前批筆試的科目結(jié)構(gòu)與篩選邏輯提前批的筆試時間一般比較緊張題量不算小題型大致可以分成三類題型常見內(nèi)容考察目標基礎(chǔ)選擇題數(shù)據(jù)庫原理、事務(wù)、索引、SQL語法知識面是否成體系手寫SQL題多表關(guān)聯(lián)、聚合統(tǒng)計、窗口函數(shù)動手能力是否過硬綜合場景題死鎖分析、慢SQL優(yōu)化、高可用設(shè)計工程思維和排錯能力出題的篩選邏輯很清晰先靠基礎(chǔ)題淘汰知識不扎實的人再靠手寫SQL淘汰“只會背概念不會寫”的人最后靠場景題找到真正有數(shù)據(jù)庫思維的人。所以備考時不要把精力全砸在背概念上手寫SQL和場景分析必須要練。2. 高頻考點拆解SQL基本功不能有短板2.1 增刪改查與多表關(guān)聯(lián)是基礎(chǔ)盤說實話SQL這一關(guān)刷掉的人比我預(yù)期的多。很多人以為“能用SELECT查數(shù)據(jù)”就算會SQL但筆試的手寫SQL題對邏輯嚴謹性要求很高。比如經(jīng)典的學(xué)生-課程-成績?nèi)黻P(guān)聯(lián)查詢看起來簡單寫出來經(jīng)常出現(xiàn)表別名混亂、GROUP BY漏字段、HAVING和WHERE混用這些小毛病。我給的訓(xùn)練建議是把日常CRUD的每個環(huán)節(jié)都過一遍包括INSERT批量插入、UPDATE與表連接一起用、DELETE配合子查詢、MERGE的處理邏輯別只停留在SELECT。筆試里考察的“數(shù)據(jù)庫增刪改查”從來不是單表操作而是多表之間的關(guān)聯(lián)和一致性維護。另外數(shù)據(jù)庫設(shè)計的基礎(chǔ)素養(yǎng)也常在這里出現(xiàn)比如三范式、ER模型、反范式設(shè)計的取舍如果你正在上數(shù)據(jù)庫課程設(shè)計別只是交差用心把表和字段之間的關(guān)系理順筆試時能省不少力。你可以用下面這個題目自測-- 表結(jié)構(gòu)students(id, name, class_id)courses(id, name) -- scores(student_id, course_id, score) -- 需求查詢每門課程分數(shù)最高的學(xué)生姓名、課程名、分數(shù) SELECT c.name AS course_name, s.name AS student_name, t.max_score FROM ( SELECT course_id, MAX(score) AS max_score FROM scores GROUP BY course_id ) t JOIN scores sc ON sc.course_id t.course_id AND sc.score t.max_score JOIN students s ON s.id sc.student_id JOIN courses c ON c.id sc.course_id ORDER BY c.name;這道題的考點很典型先聚合找出最大值再回表關(guān)聯(lián)查出對應(yīng)的學(xué)生。如果筆試里遇到這類題你還要注意分數(shù)并列的問題——如果一門課有兩個最高分子查詢方式會同時帶出多行這時要看題目是否要求去重。2.2 窗口函數(shù)筆試里的“拉分題”窗口函數(shù)是近些年校招筆試的高頻拉分點。它本質(zhì)上是在不改變結(jié)果集行數(shù)的前提下對每一行做聚合或排名計算。很多人在這里直接卡住是因為沒有理解“窗口”的范圍是怎么框定的。一個很常見的考察場景是“查詢每個部門薪資排名前兩名的員工”。用傳統(tǒng)子查詢會很繞但用窗口函數(shù)就是幾行的事SELECT department_id, employee_name, salary, rn FROM ( SELECT department_id, employee_name, salary, ROW_NUMBER() OVER (PARTITION BY department_id ORDER BY salary DESC) AS rn FROM employees ) t WHERE rn 2;這里要注意ROW_NUMBER()、RANK()、DENSE_RANK()三者的區(qū)別筆試極愛考ROW_NUMBER()生成的序號不重復(fù)RANK()遇到相同值會跳過序號DENSE_RANK()遇到相同值不跳號。你在答場景題時先看清題目問的是“前兩名”還是“前兩個名次”再決定用哪個函數(shù)。2.3 手寫SQL的通用踩坑清單SQL這部分的復(fù)習(xí)我建議你準備一個錯題本專門記錄手寫時犯的低級錯誤。我?guī)腿藦?fù)盤時發(fā)現(xiàn)最常見的幾類問題GROUP BY 查詢的字段沒有全部放進分組中導(dǎo)致結(jié)果不符合預(yù)期WHERE 和 HAVING 的過濾時機混淆WHERE 在分組前HAVING 在分組后JOIN 時忽略關(guān)聯(lián)鍵的NULL值行為INNER JOIN與LEFT JOIN結(jié)果判斷失誤題目要求保留小數(shù)或處理NULL時忘記用ROUND、IFNULL、COALESCE這類函數(shù)排序時多字段順序?qū)懛幢热纭跋劝磿r間倒序再按金額排序”和“先按金額再按時間”結(jié)果完全不同這些錯誤不是“不會”而是“手生”。筆試前兩周每天保持10道以上手寫SQL的頻率比看十遍理論書都管用。尤其是增刪改查之外的聚合統(tǒng)計和關(guān)聯(lián)查詢寧可多花時間練到條件反射也別到考場才現(xiàn)場想語法。3. 重頭戲事務(wù)、鎖與并發(fā)控制3.1 為什么ACID總被反復(fù)問數(shù)據(jù)庫管理工程師的筆試幾乎繞不開事務(wù)。原因很簡單只要系統(tǒng)的數(shù)據(jù)不能出錯事務(wù)就是保底的那道防線。ACID這四個特性不只是背定義你要能說清楚每個特性對應(yīng)到底層哪個機制。比如原子性靠undo log回滾日志保證持久性靠redo log重做日志保證隔離性靠鎖和MVCC保證一致性則是在前面三者的共同作用下實現(xiàn)的。很多同學(xué)在回答ACID時只能把四個特性背一遍但筆試更想看到的是“機制對應(yīng)”的能力。你可以自己在紙上畫一條事務(wù)的執(zhí)行路徑開啟事務(wù)、修改數(shù)據(jù)、寫undo日志、寫redo日志、提交、刷盤然后思考如果每個環(huán)節(jié)崩潰會發(fā)生什么。把這條路徑想明白選擇題和簡答題都不容易丟分。另一個常考的延伸點是“唯一索引沖突”。比如一張表里已經(jīng)有了重復(fù)數(shù)據(jù)線上卻要加唯一索引會直接報錯。正確的處理思路是先查詢重復(fù)數(shù)據(jù)保留業(yè)務(wù)上需要保留的一條清理其余數(shù)據(jù)后再創(chuàng)建唯一索引。這種題看似簡單考的是你有沒有真正操作過生產(chǎn)環(huán)境的索引變更。3.2 隔離級別與MVCC的理解誤區(qū)SQL標準定義了四種隔離級別讀未提交、讀已提交、可重復(fù)讀、串行化。MySQL默認是可重復(fù)讀這一點很多人背得住但問到“可重復(fù)讀為什么還解決不了幻讀”就答不上來了。這里有個關(guān)鍵認知必須理清InnoDB的可重復(fù)讀通過MVCC的快照讀解決了大部分幻讀問題但在當前讀的場景下仍然可能需要臨鍵鎖(Next-Key Lock)來徹底防止幻讀。MVCC的原理可以做一個生活化類比你打開一份文檔時系統(tǒng)給你一份當時的“快照”之后別人怎么改原文檔你看到的都還是快照里的內(nèi)容直到你重新打開文檔。這個設(shè)計讓讀操作不用阻塞寫操作大大提升了并發(fā)度。筆試面對這類題建議按“什么隔離級別-什么問題場景-底層什么機制解決”的框架來回答條理清楚得分點也齊全。3.3 死鎖與鎖競爭場景題怎么分析場景題里最容易讓人懵的是死鎖分析。典型題目兩個事務(wù)分別修改A、B兩條記錄執(zhí)行順序交叉時會不會死鎖答案是要看加鎖順序是否一致。事務(wù)1先鎖A再鎖B事務(wù)2先鎖B再鎖A兩個事務(wù)互相等待對方的鎖就形成了死鎖。注意分析死鎖題有個通用套路就是先各自畫“持有鎖→等待鎖”的箭頭再判斷箭頭是否成環(huán)。成環(huán)是死鎖的必要條件不成環(huán)說明只是鎖等待兩條路線的結(jié)論完全不同。數(shù)據(jù)庫檢測到死鎖通常會讓其中一個事務(wù)回滾另一個繼續(xù)執(zhí)行。你在筆試里遇到這種題可以按三步來推畫出每個事務(wù)持有的鎖和等待的鎖判斷等待關(guān)系是否形成環(huán)分析數(shù)據(jù)庫死鎖檢測機制會如何選擇犧牲者另外還要知道“數(shù)據(jù)庫死鎖”和“爭用”不是一回事。大量并發(fā)訪問同一行數(shù)據(jù)時鎖等待會很嚴重但還沒達到互等資源的死鎖程度。這時候的優(yōu)化方向是減少鎖粒度、控制事務(wù)執(zhí)行時間、合理設(shè)計索引走更少的行。筆試問“如何降低鎖競爭”答案不要只說“用樂觀鎖”而要結(jié)合具體場景講清楚替代方案。還有一個容易被忽略的點開啟數(shù)據(jù)庫審計功能后審計日志寫入如果和業(yè)務(wù)SQL爭搶系統(tǒng)資源可能引發(fā)索引爭用和鎖等待這在新增審計策略時必須提前評估。4. 索引與SQL性能優(yōu)化拉開差距的核心4.1 索引失效的常見場景索引相關(guān)題目在筆試中的占比相當高因為它是從“能查出來”到“查得快”的分水嶺。很多同學(xué)背得出“聯(lián)合索引最左前綴原則”但一給具體SQL就判斷錯。最常見的索引失效場景包括對索引列使用函數(shù)、隱式類型轉(zhuǎn)換、LIKE以百分號開頭、OR連接非索引列、聯(lián)合索引不按最左前綴使用。比如WHERE DATE(create_time) 2024-01-01會導(dǎo)致create_time上的索引失效你應(yīng)該改寫為WHERE create_time 2024-01-01 AND create_time 2024-01-02讓索引能走范圍掃描。我發(fā)現(xiàn)很多人在復(fù)習(xí)索引時只看“失效”的結(jié)果不理解底層原因。一個有用的思路是索引本質(zhì)上是一種有序結(jié)構(gòu)查詢能走索引是因為可以利用有序性快速定位。一旦對列做了函數(shù)計算原本的順序就被打破了優(yōu)化器無法再依靠索引進行快速定位只能回表掃描。把這一條想明白判斷索引失效題就不會錯。4.2 執(zhí)行計劃怎么讀筆試場景題里常給出一段慢SQL讓你分析原因并優(yōu)化。這時執(zhí)行計劃就是你最重要的依據(jù)。優(yōu)先看幾個關(guān)鍵字段字段含義關(guān)注點type訪問類型從system到ALL走全表掃描就要警惕key實際使用的索引NULL表示沒走索引rows預(yù)估掃描行數(shù)與最終性能強相關(guān)Extra額外信息Using filesort、Using temporary要優(yōu)化比如Extra里出現(xiàn)Using filesort說明排序沒有用到索引可以考慮在ORDER BY字段上建立合適的聯(lián)合索引。出現(xiàn)Using temporary通常意味著GROUP BY或去重操作創(chuàng)建了臨時表數(shù)據(jù)量大時性能會很差。優(yōu)化方向往往是改寫SQL或者調(diào)整索引讓操作能走索引順序完成。這里我要提醒你筆試中的執(zhí)行計劃題不會讓你真的去生產(chǎn)環(huán)境跑EXPLAIN但你要能根據(jù)給出的計劃片段判斷瓶頸。復(fù)習(xí)時可以自己在本地建一張幾萬行的表跑一跑EXPLAIN嘗試用不同索引和SQL寫法對比rows和Extra的變化這個過程能幫你形成非常直觀的“索引手感”。本地可以用SQLite或者MySQL都行不用太在意數(shù)據(jù)庫版本差異重點是理解優(yōu)化器關(guān)注的核心因素。4.3 慢SQL優(yōu)化思路框架遇到慢SQL優(yōu)化題我建議按固定框架作答避免漏掉得分點。首先是定位問題用慢查詢?nèi)罩净蛘邎?zhí)行計劃找出是哪一步耗時最高。其次是改寫SQL減少不回表的掃描行數(shù)、消除不必要的DISTINCT和ORDER BY、把子查詢改寫成JOIN或反向改寫。然后是索引優(yōu)化根據(jù)WHERE過濾、JOIN關(guān)聯(lián)、ORDER BY排序字段選擇合適的單列索引或聯(lián)合索引。最后還有一個容易被忽略的點把業(yè)務(wù)需求看清楚。我見過不少人把一條查詢改得花里胡哨結(jié)果業(yè)務(wù)上其實只需要5條數(shù)據(jù)加個LIMIT就能大幅降級掃描成本。數(shù)據(jù)庫優(yōu)化不是炫技而是理解業(yè)務(wù)后做最小代價的調(diào)整這一點在綜合場景題里特別加分。如果你在開發(fā)中經(jīng)常使用ORM框架也要能識別ORM生成的SQL和手寫SQL之間的性能差異筆試有時會讓你判斷一段ORM操作對應(yīng)到數(shù)據(jù)庫層面的真實代價。5. 數(shù)據(jù)庫管理與高可用實踐工程師的“本行”5.1 主從復(fù)制與常見高可用方案數(shù)據(jù)庫管理工程師和開發(fā)崗的一個明顯差異就是筆試會涉及很多日常運維和架構(gòu)層面的知識。主從復(fù)制幾乎是必考的基礎(chǔ)點主庫把變更寫入二進制日志從庫的I/O線程拉取日志并寫入中繼日志SQL線程再重放中繼日志完成數(shù)據(jù)同步。這個鏈路中的每一步都可能出問題筆試常問“主從延遲怎么排查”答案方向通常是查看從庫Seconds_Behind_Master指標、分析是否有大事務(wù)、檢查從庫所在機器的磁盤或CPU壓力、確認是否缺少主鍵導(dǎo)致回放慢。高可用方案也是考察熱點。如果問到傳統(tǒng)的主從切換和MGR這類方案的區(qū)別你可以從數(shù)據(jù)一致性、故障自動檢測、腦裂處理等角度展開。注意不要只背方案名稱而要理解每個方案的權(quán)衡強調(diào)高可用可能會犧牲一點故障切換的時間強調(diào)數(shù)據(jù)一致性又可能在某些場景降低可用性。能在筆試里把權(quán)衡關(guān)系講清楚的人明顯更受面試官喜歡。數(shù)據(jù)同步也是這個崗位繞不開的話題。無論是跨機房同步、異構(gòu)數(shù)據(jù)庫同步還是把線上庫導(dǎo)入分析庫都會用到各類數(shù)據(jù)庫同步軟件或工具。筆試里不一定會讓你寫工具名但你要理解同步的本質(zhì)是“日志抓取轉(zhuǎn)換回放”并且知道同步延遲、數(shù)據(jù)沖突、斷點續(xù)傳這幾個核心問題是怎么被解決的。5.2 備份恢復(fù)與數(shù)據(jù)安全備份恢復(fù)是數(shù)據(jù)庫管理者的基本功也會以場景題形式出現(xiàn)在筆試里。你需要理解物理備份和邏輯備份的區(qū)別物理備份直接拷貝數(shù)據(jù)文件恢復(fù)快但對版本和平臺敏感邏輯備份導(dǎo)出SQL或文本格式數(shù)據(jù)靈活性強但恢復(fù)慢。還要知道全量備份、增量備份、差異備份的適用場景。有一個高頻問答是“誤刪了生產(chǎn)表數(shù)據(jù)怎么盡快恢復(fù)”。完整的思路是先看有沒有最近的全量備份再看備份之后有沒有歸檔日志或binlog然后通過binlog按時間點回放找回數(shù)據(jù)。這類題考察的不是具體命令而是你對“備份鏈”有沒有完整認知。還值得提醒的是備份要定期做恢復(fù)演練否則備份文件可能是壞的這個坑在真實工作中非常常見筆試答出來會顯得很有實戰(zhàn)經(jīng)驗。關(guān)于數(shù)據(jù)安全還有一個角度就是權(quán)限管理和審計。最小權(quán)限原則、分離管理員與業(yè)務(wù)賬號、敏感數(shù)據(jù)脫敏這些概念在開放題里都可能出現(xiàn)。數(shù)據(jù)庫審計本身是把雙刃劍審計能增強安全但不加評估地開啟審計日志量的暴增可能引入嚴重的性能問題甚至加劇索引爭用回答時能把“安全”和“性能”的平衡說出來層次會高很多。5.3 數(shù)據(jù)庫生態(tài)與國產(chǎn)數(shù)據(jù)庫的認知儲備這幾年國產(chǎn)數(shù)據(jù)庫的討論度很高網(wǎng)易這類大廠校招筆試里也偶爾會出現(xiàn)開放性問題比如“如何看待國產(chǎn)數(shù)據(jù)庫的發(fā)展”“數(shù)據(jù)庫選型會考慮哪些因素”。這類題不要求你精通達夢、人大金倉、GaussDB、OceanBase等產(chǎn)品的細節(jié)但至少要有基礎(chǔ)認知了解它們多數(shù)基于PostgreSQL或MySQL生態(tài)發(fā)展而來了解國產(chǎn)數(shù)據(jù)庫面臨的兼容性、生態(tài)工具鏈、遷移成本等問題。我建議準備這個方向時不要去背“國產(chǎn)數(shù)據(jù)庫排名前十名”這類文章而是圍繞三條主線整理自己的觀點一是兼容性遷移從Oracle或MySQL遷來要改什么二是生態(tài)工具數(shù)據(jù)同步、監(jiān)控、備份工具是否齊全三是核心場景的穩(wěn)定性案例。能在筆試里說出“選型不是選數(shù)據(jù)庫本身而是選整個生態(tài)”這種有深度的觀點會讓整份答卷顯得成熟很多。數(shù)據(jù)庫生態(tài)里還可以順帶準備一下新興方向。比如時序數(shù)據(jù)庫適合監(jiān)控指標和物聯(lián)網(wǎng)數(shù)據(jù)向量數(shù)據(jù)庫更適合大模型的相似度檢索場景。這類開放題不要求你寫底層實現(xiàn)但至少要能說出它們各自解決什么問題、和傳統(tǒng)關(guān)系型數(shù)據(jù)庫的區(qū)別是什么。知道這些遇到開放性提問時你不會無話可說。6. 復(fù)習(xí)路徑與投遞建議怎么準備最高效6.1 三輪復(fù)習(xí)法針對網(wǎng)易校招數(shù)據(jù)庫管理工程師這類崗位的筆試我比較推薦三輪復(fù)習(xí)法時間充?？梢岳L到四到六周時間緊張最少保證三周。第一輪打基礎(chǔ)用3到5天系統(tǒng)過一遍數(shù)據(jù)庫原理重點吃透事務(wù)、索引、鎖、SQL標準概念。這一輪不要貪多目標是形成知識地圖知道每個知識點在哪個模塊下。第二輪刷題強化用7到10天集中刷數(shù)據(jù)庫面試題和SQL題。這一輪要專門整理錯題把每一道錯題映射回知識點找出是概念不清、原理不明還是手寫能力不足。注意現(xiàn)在的熱詞和題目趨勢也在變化比如“數(shù)據(jù)庫面試題”“數(shù)據(jù)庫并發(fā)鎖”“數(shù)據(jù)庫死鎖”這些方向容易被反復(fù)翻新考察刷題時要多歸納同一知識點的不同問法。第三輪實戰(zhàn)模擬考前3到5天按筆試的時間要求做整套模擬題鍛煉答題節(jié)奏。手寫SQL題目要實際寫在紙上或編輯器里不要只在腦中過一遍避免考試時手生。最后把錯題本從頭到尾過一遍狀態(tài)就基本到位了。6.2 值得投入時間的具體清單結(jié)合筆試考察重點我列一個“投入產(chǎn)出比較高”的復(fù)習(xí)清單你可以直接對照自查模塊必須掌握的點建議投入SQL多表關(guān)聯(lián)、聚合、窗口函數(shù)、子查詢每天手寫10題事務(wù)與鎖ACID機制、隔離級別、MVCC、死鎖分析深挖原理2天索引優(yōu)化失效場景、執(zhí)行計劃、慢SQL優(yōu)化結(jié)合實際EXPLAIN練習(xí)高可用與運維主從復(fù)制、備份恢復(fù)、高可用方案講清原理方案對比數(shù)據(jù)庫生態(tài)國產(chǎn)數(shù)據(jù)庫、同步工具、選型思路準備2個觀點來表達這個清單不是我拍腦袋寫的而是把近幾年校招數(shù)據(jù)庫崗的考察熱點壓縮后的結(jié)果。你不用面面俱到但每個模塊至少要有能講透的程度筆試基礎(chǔ)分就穩(wěn)了。順帶說一下數(shù)據(jù)庫實例層面的知識也別完全空白比如給SQLite這類單文件數(shù)據(jù)庫做一次完整的建庫、建表、查詢操作體驗一遍“數(shù)據(jù)庫軟件”從安裝到使用的基本流程能幫你建立對數(shù)據(jù)庫工具鏈的直觀感覺。6.3 投遞與筆試心態(tài)上的建議最后一個建議是關(guān)于投遞節(jié)奏的。提前批的特點是開啟早、流程快如果你還處于“先投遞再復(fù)習(xí)”的狀態(tài)風(fēng)險很大。我見過太多人提前批投完筆試通知一到手才發(fā)現(xiàn)自己連SQL都手生只能硬著頭皮上。正確做法是決定投遞的那一刻就開始按清單復(fù)習(xí)收到筆試邀約后再做針對性的沖刺和模擬。筆試過程中遇到不會的題先跳過去做后面會的別在一道場景題上耗太久。數(shù)據(jù)庫管理工程師崗位的題量通常不小答完比答完美更重要。即使最后沒有通過提前批也不用灰心正式批通常還有機會提前批的筆試復(fù)盤本身就是一次高價值的訓(xùn)練。我自己帶團隊面試時最怕看到的就是候選人背了一堆“八股定理”但一問“這個機制在什么場景下會出問題”就啞火。網(wǎng)易杭研數(shù)據(jù)庫管理工程師筆試的考點其實都在圍繞一個核心問題轉(zhuǎn)你有沒有真正用數(shù)據(jù)庫處理過問題而不是只背過數(shù)據(jù)庫。復(fù)習(xí)到最后你會發(fā)現(xiàn)所有知識都是串起來的——SQL查不快就回到索引索引亂了就回到數(shù)據(jù)分布數(shù)據(jù)出錯了就回到事務(wù)和鎖。把這條主線理清筆試只是順帶的事。 網(wǎng)易校招數(shù)據(jù)庫管理工程師筆試備考：SQL、事務(wù)與索引優(yōu)化全攻略
網(wǎng)易2023校招提前批放出的數(shù)據(jù)庫管理工程師杭研崗位筆試到底考什么、怎么準備是很多準備校招的同學(xué)最關(guān)心的問題。我前后參與過不少校招出題和評審工作也幫團隊篩過大量簡歷可以負責任地說數(shù)據(jù)庫管理工程師的筆試和開發(fā)崗是兩條完全不同的線算法題不是主角真正拉開差距的是數(shù)據(jù)庫原理、SQL基本功、事務(wù)與鎖、索引與性能優(yōu)化、高可用與日常運維這些硬核模塊。這篇文章不涉及任何具體真題保密范圍內(nèi)我也拿不到而是按崗位的普遍考察規(guī)律整理出一條可落地的備考主線。它適合正在準備網(wǎng)易校招的同學(xué)也適合所有想往數(shù)據(jù)庫方向走的求職者參考。1. 崗位畫像與筆試考察邏輯1.1 數(shù)據(jù)庫管理工程師在杭研做什么數(shù)據(jù)庫管理工程師這個崗位在校招里經(jīng)常被誤解成“高級DBA”。實際上杭研這類互聯(lián)網(wǎng)公司的數(shù)據(jù)庫管理工程師職責范圍比傳統(tǒng)DBA更寬既要管數(shù)據(jù)庫的日常穩(wěn)定運行也要參與業(yè)務(wù)側(cè)的數(shù)據(jù)庫設(shè)計、SQL審核、慢查詢治理、容量規(guī)劃還會涉及數(shù)據(jù)同步、備份恢復(fù)、高可用架構(gòu)的落地。說白了這個崗位要的是“能聽懂業(yè)務(wù)也能搞定數(shù)據(jù)庫底層”的人。這和后端開發(fā)崗位的最大區(qū)別在于后端開發(fā)寫業(yè)務(wù)邏輯數(shù)據(jù)庫管理工程師是在“伺候”支撐業(yè)務(wù)的數(shù)據(jù)底座。筆試也因此不會考太多算法題反而更看重對數(shù)據(jù)庫內(nèi)核機制的理解深度和工程手感。理解了這一點你就能明白為什么筆試的重點是那些“看似基礎(chǔ)、實則能拉開差距”的數(shù)據(jù)庫知識點。1.2 提前批筆試的科目結(jié)構(gòu)與篩選邏輯提前批的筆試時間一般比較緊張題量不算小題型大致可以分成三類題型常見內(nèi)容考察目標基礎(chǔ)選擇題數(shù)據(jù)庫原理、事務(wù)、索引、SQL語法知識面是否成體系手寫SQL題多表關(guān)聯(lián)、聚合統(tǒng)計、窗口函數(shù)動手能力是否過硬綜合場景題死鎖分析、慢SQL優(yōu)化、高可用設(shè)計工程思維和排錯能力出題的篩選邏輯很清晰先靠基礎(chǔ)題淘汰知識不扎實的人再靠手寫SQL淘汰“只會背概念不會寫”的人最后靠場景題找到真正有數(shù)據(jù)庫思維的人。所以備考時不要把精力全砸在背概念上手寫SQL和場景分析必須要練。2. 高頻考點拆解SQL基本功不能有短板2.1 增刪改查與多表關(guān)聯(lián)是基礎(chǔ)盤說實話SQL這一關(guān)刷掉的人比我預(yù)期的多。很多人以為“能用SELECT查數(shù)據(jù)”就算會SQL但筆試的手寫SQL題對邏輯嚴謹性要求很高。比如經(jīng)典的學(xué)生-課程-成績?nèi)黻P(guān)聯(lián)查詢看起來簡單寫出來經(jīng)常出現(xiàn)表別名混亂、GROUP BY漏字段、HAVING和WHERE混用這些小毛病。我給的訓(xùn)練建議是把日常CRUD的每個環(huán)節(jié)都過一遍包括INSERT批量插入、UPDATE與表連接一起用、DELETE配合子查詢、MERGE的處理邏輯別只停留在SELECT。筆試里考察的“數(shù)據(jù)庫增刪改查”從來不是單表操作而是多表之間的關(guān)聯(lián)和一致性維護。另外數(shù)據(jù)庫設(shè)計的基礎(chǔ)素養(yǎng)也常在這里出現(xiàn)比如三范式、ER模型、反范式設(shè)計的取舍如果你正在上數(shù)據(jù)庫課程設(shè)計別只是交差用心把表和字段之間的關(guān)系理順筆試時能省不少力。你可以用下面這個題目自測-- 表結(jié)構(gòu)students(id, name, class_id)courses(id, name) -- scores(student_id, course_id, score) -- 需求查詢每門課程分數(shù)最高的學(xué)生姓名、課程名、分數(shù) SELECT c.name AS course_name, s.name AS student_name, t.max_score FROM ( SELECT course_id, MAX(score) AS max_score FROM scores GROUP BY course_id ) t JOIN scores sc ON sc.course_id t.course_id AND sc.score t.max_score JOIN students s ON s.id sc.student_id JOIN courses c ON c.id sc.course_id ORDER BY c.name;這道題的考點很典型先聚合找出最大值再回表關(guān)聯(lián)查出對應(yīng)的學(xué)生。如果筆試里遇到這類題你還要注意分數(shù)并列的問題——如果一門課有兩個最高分子查詢方式會同時帶出多行這時要看題目是否要求去重。2.2 窗口函數(shù)筆試里的“拉分題”窗口函數(shù)是近些年校招筆試的高頻拉分點。它本質(zhì)上是在不改變結(jié)果集行數(shù)的前提下對每一行做聚合或排名計算。很多人在這里直接卡住是因為沒有理解“窗口”的范圍是怎么框定的。一個很常見的考察場景是“查詢每個部門薪資排名前兩名的員工”。用傳統(tǒng)子查詢會很繞但用窗口函數(shù)就是幾行的事SELECT department_id, employee_name, salary, rn FROM ( SELECT department_id, employee_name, salary, ROW_NUMBER() OVER (PARTITION BY department_id ORDER BY salary DESC) AS rn FROM employees ) t WHERE rn 2;這里要注意ROW_NUMBER()、RANK()、DENSE_RANK()三者的區(qū)別筆試極愛考ROW_NUMBER()生成的序號不重復(fù)RANK()遇到相同值會跳過序號DENSE_RANK()遇到相同值不跳號。你在答場景題時先看清題目問的是“前兩名”還是“前兩個名次”再決定用哪個函數(shù)。2.3 手寫SQL的通用踩坑清單SQL這部分的復(fù)習(xí)我建議你準備一個錯題本專門記錄手寫時犯的低級錯誤。我?guī)腿藦?fù)盤時發(fā)現(xiàn)最常見的幾類問題GROUP BY 查詢的字段沒有全部放進分組中導(dǎo)致結(jié)果不符合預(yù)期WHERE 和 HAVING 的過濾時機混淆WHERE 在分組前HAVING 在分組后JOIN 時忽略關(guān)聯(lián)鍵的NULL值行為INNER JOIN與LEFT JOIN結(jié)果判斷失誤題目要求保留小數(shù)或處理NULL時忘記用ROUND、IFNULL、COALESCE這類函數(shù)排序時多字段順序?qū)懛幢热纭跋劝磿r間倒序再按金額排序”和“先按金額再按時間”結(jié)果完全不同這些錯誤不是“不會”而是“手生”。筆試前兩周每天保持10道以上手寫SQL的頻率比看十遍理論書都管用。尤其是增刪改查之外的聚合統(tǒng)計和關(guān)聯(lián)查詢寧可多花時間練到條件反射也別到考場才現(xiàn)場想語法。3. 重頭戲事務(wù)、鎖與并發(fā)控制3.1 為什么ACID總被反復(fù)問數(shù)據(jù)庫管理工程師的筆試幾乎繞不開事務(wù)。原因很簡單只要系統(tǒng)的數(shù)據(jù)不能出錯事務(wù)就是保底的那道防線。ACID這四個特性不只是背定義你要能說清楚每個特性對應(yīng)到底層哪個機制。比如原子性靠undo log回滾日志保證持久性靠redo log重做日志保證隔離性靠鎖和MVCC保證一致性則是在前面三者的共同作用下實現(xiàn)的。很多同學(xué)在回答ACID時只能把四個特性背一遍但筆試更想看到的是“機制對應(yīng)”的能力。你可以自己在紙上畫一條事務(wù)的執(zhí)行路徑開啟事務(wù)、修改數(shù)據(jù)、寫undo日志、寫redo日志、提交、刷盤然后思考如果每個環(huán)節(jié)崩潰會發(fā)生什么。把這條路徑想明白選擇題和簡答題都不容易丟分。另一個常考的延伸點是“唯一索引沖突”。比如一張表里已經(jīng)有了重復(fù)數(shù)據(jù)線上卻要加唯一索引會直接報錯。正確的處理思路是先查詢重復(fù)數(shù)據(jù)保留業(yè)務(wù)上需要保留的一條清理其余數(shù)據(jù)后再創(chuàng)建唯一索引。這種題看似簡單考的是你有沒有真正操作過生產(chǎn)環(huán)境的索引變更。3.2 隔離級別與MVCC的理解誤區(qū)SQL標準定義了四種隔離級別讀未提交、讀已提交、可重復(fù)讀、串行化。MySQL默認是可重復(fù)讀這一點很多人背得住但問到“可重復(fù)讀為什么還解決不了幻讀”就答不上來了。這里有個關(guān)鍵認知必須理清InnoDB的可重復(fù)讀通過MVCC的快照讀解決了大部分幻讀問題但在當前讀的場景下仍然可能需要臨鍵鎖(Next-Key Lock)來徹底防止幻讀。MVCC的原理可以做一個生活化類比你打開一份文檔時系統(tǒng)給你一份當時的“快照”之后別人怎么改原文檔你看到的都還是快照里的內(nèi)容直到你重新打開文檔。這個設(shè)計讓讀操作不用阻塞寫操作大大提升了并發(fā)度。筆試面對這類題建議按“什么隔離級別-什么問題場景-底層什么機制解決”的框架來回答條理清楚得分點也齊全。3.3 死鎖與鎖競爭場景題怎么分析場景題里最容易讓人懵的是死鎖分析。典型題目兩個事務(wù)分別修改A、B兩條記錄執(zhí)行順序交叉時會不會死鎖答案是要看加鎖順序是否一致。事務(wù)1先鎖A再鎖B事務(wù)2先鎖B再鎖A兩個事務(wù)互相等待對方的鎖就形成了死鎖。注意分析死鎖題有個通用套路就是先各自畫“持有鎖→等待鎖”的箭頭再判斷箭頭是否成環(huán)。成環(huán)是死鎖的必要條件不成環(huán)說明只是鎖等待兩條路線的結(jié)論完全不同。數(shù)據(jù)庫檢測到死鎖通常會讓其中一個事務(wù)回滾另一個繼續(xù)執(zhí)行。你在筆試里遇到這種題可以按三步來推畫出每個事務(wù)持有的鎖和等待的鎖判斷等待關(guān)系是否形成環(huán)分析數(shù)據(jù)庫死鎖檢測機制會如何選擇犧牲者另外還要知道“數(shù)據(jù)庫死鎖”和“爭用”不是一回事。大量并發(fā)訪問同一行數(shù)據(jù)時鎖等待會很嚴重但還沒達到互等資源的死鎖程度。這時候的優(yōu)化方向是減少鎖粒度、控制事務(wù)執(zhí)行時間、合理設(shè)計索引走更少的行。筆試問“如何降低鎖競爭”答案不要只說“用樂觀鎖”而要結(jié)合具體場景講清楚替代方案。還有一個容易被忽略的點開啟數(shù)據(jù)庫審計功能后審計日志寫入如果和業(yè)務(wù)SQL爭搶系統(tǒng)資源可能引發(fā)索引爭用和鎖等待這在新增審計策略時必須提前評估。4. 索引與SQL性能優(yōu)化拉開差距的核心4.1 索引失效的常見場景索引相關(guān)題目在筆試中的占比相當高因為它是從“能查出來”到“查得快”的分水嶺。很多同學(xué)背得出“聯(lián)合索引最左前綴原則”但一給具體SQL就判斷錯。最常見的索引失效場景包括對索引列使用函數(shù)、隱式類型轉(zhuǎn)換、LIKE以百分號開頭、OR連接非索引列、聯(lián)合索引不按最左前綴使用。比如WHERE DATE(create_time) 2024-01-01會導(dǎo)致create_time上的索引失效你應(yīng)該改寫為WHERE create_time 2024-01-01 AND create_time 2024-01-02讓索引能走范圍掃描。我發(fā)現(xiàn)很多人在復(fù)習(xí)索引時只看“失效”的結(jié)果不理解底層原因。一個有用的思路是索引本質(zhì)上是一種有序結(jié)構(gòu)查詢能走索引是因為可以利用有序性快速定位。一旦對列做了函數(shù)計算原本的順序就被打破了優(yōu)化器無法再依靠索引進行快速定位只能回表掃描。把這一條想明白判斷索引失效題就不會錯。4.2 執(zhí)行計劃怎么讀筆試場景題里常給出一段慢SQL讓你分析原因并優(yōu)化。這時執(zhí)行計劃就是你最重要的依據(jù)。優(yōu)先看幾個關(guān)鍵字段字段含義關(guān)注點type訪問類型從system到ALL走全表掃描就要警惕key實際使用的索引NULL表示沒走索引rows預(yù)估掃描行數(shù)與最終性能強相關(guān)Extra額外信息Using filesort、Using temporary要優(yōu)化比如Extra里出現(xiàn)Using filesort說明排序沒有用到索引可以考慮在ORDER BY字段上建立合適的聯(lián)合索引。出現(xiàn)Using temporary通常意味著GROUP BY或去重操作創(chuàng)建了臨時表數(shù)據(jù)量大時性能會很差。優(yōu)化方向往往是改寫SQL或者調(diào)整索引讓操作能走索引順序完成。這里我要提醒你筆試中的執(zhí)行計劃題不會讓你真的去生產(chǎn)環(huán)境跑EXPLAIN但你要能根據(jù)給出的計劃片段判斷瓶頸。復(fù)習(xí)時可以自己在本地建一張幾萬行的表跑一跑EXPLAIN嘗試用不同索引和SQL寫法對比rows和Extra的變化這個過程能幫你形成非常直觀的“索引手感”。本地可以用SQLite或者MySQL都行不用太在意數(shù)據(jù)庫版本差異重點是理解優(yōu)化器關(guān)注的核心因素。4.3 慢SQL優(yōu)化思路框架遇到慢SQL優(yōu)化題我建議按固定框架作答避免漏掉得分點。首先是定位問題用慢查詢?nèi)罩净蛘邎?zhí)行計劃找出是哪一步耗時最高。其次是改寫SQL減少不回表的掃描行數(shù)、消除不必要的DISTINCT和ORDER BY、把子查詢改寫成JOIN或反向改寫。然后是索引優(yōu)化根據(jù)WHERE過濾、JOIN關(guān)聯(lián)、ORDER BY排序字段選擇合適的單列索引或聯(lián)合索引。最后還有一個容易被忽略的點把業(yè)務(wù)需求看清楚。我見過不少人把一條查詢改得花里胡哨結(jié)果業(yè)務(wù)上其實只需要5條數(shù)據(jù)加個LIMIT就能大幅降級掃描成本。數(shù)據(jù)庫優(yōu)化不是炫技而是理解業(yè)務(wù)后做最小代價的調(diào)整這一點在綜合場景題里特別加分。如果你在開發(fā)中經(jīng)常使用ORM框架也要能識別ORM生成的SQL和手寫SQL之間的性能差異筆試有時會讓你判斷一段ORM操作對應(yīng)到數(shù)據(jù)庫層面的真實代價。5. 數(shù)據(jù)庫管理與高可用實踐工程師的“本行”5.1 主從復(fù)制與常見高可用方案數(shù)據(jù)庫管理工程師和開發(fā)崗的一個明顯差異就是筆試會涉及很多日常運維和架構(gòu)層面的知識。主從復(fù)制幾乎是必考的基礎(chǔ)點主庫把變更寫入二進制日志從庫的I/O線程拉取日志并寫入中繼日志SQL線程再重放中繼日志完成數(shù)據(jù)同步。這個鏈路中的每一步都可能出問題筆試常問“主從延遲怎么排查”答案方向通常是查看從庫Seconds_Behind_Master指標、分析是否有大事務(wù)、檢查從庫所在機器的磁盤或CPU壓力、確認是否缺少主鍵導(dǎo)致回放慢。高可用方案也是考察熱點。如果問到傳統(tǒng)的主從切換和MGR這類方案的區(qū)別你可以從數(shù)據(jù)一致性、故障自動檢測、腦裂處理等角度展開。注意不要只背方案名稱而要理解每個方案的權(quán)衡強調(diào)高可用可能會犧牲一點故障切換的時間強調(diào)數(shù)據(jù)一致性又可能在某些場景降低可用性。能在筆試里把權(quán)衡關(guān)系講清楚的人明顯更受面試官喜歡。數(shù)據(jù)同步也是這個崗位繞不開的話題。無論是跨機房同步、異構(gòu)數(shù)據(jù)庫同步還是把線上庫導(dǎo)入分析庫都會用到各類數(shù)據(jù)庫同步軟件或工具。筆試里不一定會讓你寫工具名但你要理解同步的本質(zhì)是“日志抓取轉(zhuǎn)換回放”并且知道同步延遲、數(shù)據(jù)沖突、斷點續(xù)傳這幾個核心問題是怎么被解決的。5.2 備份恢復(fù)與數(shù)據(jù)安全備份恢復(fù)是數(shù)據(jù)庫管理者的基本功也會以場景題形式出現(xiàn)在筆試里。你需要理解物理備份和邏輯備份的區(qū)別物理備份直接拷貝數(shù)據(jù)文件恢復(fù)快但對版本和平臺敏感邏輯備份導(dǎo)出SQL或文本格式數(shù)據(jù)靈活性強但恢復(fù)慢。還要知道全量備份、增量備份、差異備份的適用場景。有一個高頻問答是“誤刪了生產(chǎn)表數(shù)據(jù)怎么盡快恢復(fù)”。完整的思路是先看有沒有最近的全量備份再看備份之后有沒有歸檔日志或binlog然后通過binlog按時間點回放找回數(shù)據(jù)。這類題考察的不是具體命令而是你對“備份鏈”有沒有完整認知。還值得提醒的是備份要定期做恢復(fù)演練否則備份文件可能是壞的這個坑在真實工作中非常常見筆試答出來會顯得很有實戰(zhàn)經(jīng)驗。關(guān)于數(shù)據(jù)安全還有一個角度就是權(quán)限管理和審計。最小權(quán)限原則、分離管理員與業(yè)務(wù)賬號、敏感數(shù)據(jù)脫敏這些概念在開放題里都可能出現(xiàn)。數(shù)據(jù)庫審計本身是把雙刃劍審計能增強安全但不加評估地開啟審計日志量的暴增可能引入嚴重的性能問題甚至加劇索引爭用回答時能把“安全”和“性能”的平衡說出來層次會高很多。5.3 數(shù)據(jù)庫生態(tài)與國產(chǎn)數(shù)據(jù)庫的認知儲備這幾年國產(chǎn)數(shù)據(jù)庫的討論度很高網(wǎng)易這類大廠校招筆試里也偶爾會出現(xiàn)開放性問題比如“如何看待國產(chǎn)數(shù)據(jù)庫的發(fā)展”“數(shù)據(jù)庫選型會考慮哪些因素”。這類題不要求你精通達夢、人大金倉、GaussDB、OceanBase等產(chǎn)品的細節(jié)但至少要有基礎(chǔ)認知了解它們多數(shù)基于PostgreSQL或MySQL生態(tài)發(fā)展而來了解國產(chǎn)數(shù)據(jù)庫面臨的兼容性、生態(tài)工具鏈、遷移成本等問題。我建議準備這個方向時不要去背“國產(chǎn)數(shù)據(jù)庫排名前十名”這類文章而是圍繞三條主線整理自己的觀點一是兼容性遷移從Oracle或MySQL遷來要改什么二是生態(tài)工具數(shù)據(jù)同步、監(jiān)控、備份工具是否齊全三是核心場景的穩(wěn)定性案例。能在筆試里說出“選型不是選數(shù)據(jù)庫本身而是選整個生態(tài)”這種有深度的觀點會讓整份答卷顯得成熟很多。數(shù)據(jù)庫生態(tài)里還可以順帶準備一下新興方向。比如時序數(shù)據(jù)庫適合監(jiān)控指標和物聯(lián)網(wǎng)數(shù)據(jù)向量數(shù)據(jù)庫更適合大模型的相似度檢索場景。這類開放題不要求你寫底層實現(xiàn)但至少要能說出它們各自解決什么問題、和傳統(tǒng)關(guān)系型數(shù)據(jù)庫的區(qū)別是什么。知道這些遇到開放性提問時你不會無話可說。6. 復(fù)習(xí)路徑與投遞建議怎么準備最高效6.1 三輪復(fù)習(xí)法針對網(wǎng)易校招數(shù)據(jù)庫管理工程師這類崗位的筆試我比較推薦三輪復(fù)習(xí)法時間充?？梢岳L到四到六周時間緊張最少保證三周。第一輪打基礎(chǔ)用3到5天系統(tǒng)過一遍數(shù)據(jù)庫原理重點吃透事務(wù)、索引、鎖、SQL標準概念。這一輪不要貪多目標是形成知識地圖知道每個知識點在哪個模塊下。第二輪刷題強化用7到10天集中刷數(shù)據(jù)庫面試題和SQL題。這一輪要專門整理錯題把每一道錯題映射回知識點找出是概念不清、原理不明還是手寫能力不足。注意現(xiàn)在的熱詞和題目趨勢也在變化比如“數(shù)據(jù)庫面試題”“數(shù)據(jù)庫并發(fā)鎖”“數(shù)據(jù)庫死鎖”這些方向容易被反復(fù)翻新考察刷題時要多歸納同一知識點的不同問法。第三輪實戰(zhàn)模擬考前3到5天按筆試的時間要求做整套模擬題鍛煉答題節(jié)奏。手寫SQL題目要實際寫在紙上或編輯器里不要只在腦中過一遍避免考試時手生。最后把錯題本從頭到尾過一遍狀態(tài)就基本到位了。6.2 值得投入時間的具體清單結(jié)合筆試考察重點我列一個“投入產(chǎn)出比較高”的復(fù)習(xí)清單你可以直接對照自查模塊必須掌握的點建議投入SQL多表關(guān)聯(lián)、聚合、窗口函數(shù)、子查詢每天手寫10題事務(wù)與鎖ACID機制、隔離級別、MVCC、死鎖分析深挖原理2天索引優(yōu)化失效場景、執(zhí)行計劃、慢SQL優(yōu)化結(jié)合實際EXPLAIN練習(xí)高可用與運維主從復(fù)制、備份恢復(fù)、高可用方案講清原理方案對比數(shù)據(jù)庫生態(tài)國產(chǎn)數(shù)據(jù)庫、同步工具、選型思路準備2個觀點來表達這個清單不是我拍腦袋寫的而是把近幾年校招數(shù)據(jù)庫崗的考察熱點壓縮后的結(jié)果。你不用面面俱到但每個模塊至少要有能講透的程度筆試基礎(chǔ)分就穩(wěn)了。順帶說一下數(shù)據(jù)庫實例層面的知識也別完全空白比如給SQLite這類單文件數(shù)據(jù)庫做一次完整的建庫、建表、查詢操作體驗一遍“數(shù)據(jù)庫軟件”從安裝到使用的基本流程能幫你建立對數(shù)據(jù)庫工具鏈的直觀感覺。6.3 投遞與筆試心態(tài)上的建議最后一個建議是關(guān)于投遞節(jié)奏的。提前批的特點是開啟早、流程快如果你還處于“先投遞再復(fù)習(xí)”的狀態(tài)風(fēng)險很大。我見過太多人提前批投完筆試通知一到手才發(fā)現(xiàn)自己連SQL都手生只能硬著頭皮上。正確做法是決定投遞的那一刻就開始按清單復(fù)習(xí)收到筆試邀約后再做針對性的沖刺和模擬。筆試過程中遇到不會的題先跳過去做后面會的別在一道場景題上耗太久。數(shù)據(jù)庫管理工程師崗位的題量通常不小答完比答完美更重要。即使最后沒有通過提前批也不用灰心正式批通常還有機會提前批的筆試復(fù)盤本身就是一次高價值的訓(xùn)練。我自己帶團隊面試時最怕看到的就是候選人背了一堆“八股定理”但一問“這個機制在什么場景下會出問題”就啞火。網(wǎng)易杭研數(shù)據(jù)庫管理工程師筆試的考點其實都在圍繞一個核心問題轉(zhuǎn)你有沒有真正用數(shù)據(jù)庫處理過問題而不是只背過數(shù)據(jù)庫。復(fù)習(xí)到最后你會發(fā)現(xiàn)所有知識都是串起來的——SQL查不快就回到索引索引亂了就回到數(shù)據(jù)分布數(shù)據(jù)出錯了就回到事務(wù)和鎖。把這條主線理清筆試只是順帶的事。