筆試出來那天下著小雨我在地鐵上把手機(jī)里的備忘錄翻來覆去地劃腦子里全是幾張沒把握的SQL題和一些模棱兩可的概念判斷。2023年度小滿春招數(shù)據(jù)庫崗第三批筆試整體題量不算夸張但出題思路比我想象中更貼近生產(chǎn)環(huán)境不是那種背背八股就能過的卷子。它考察的范圍覆蓋了SQL基本功、事務(wù)與鎖機(jī)制、索引優(yōu)化、數(shù)據(jù)庫架構(gòu)設(shè)計(jì)還有國產(chǎn)數(shù)據(jù)庫和工具鏈的認(rèn)知而且很多題都包裝成了實(shí)際業(yè)務(wù)場景。這篇文章就是我對這批筆試的完整復(fù)盤從題型分布到高頻考點(diǎn)再到踩坑教訓(xùn)和備戰(zhàn)建議希望能給接下來要參加同類崗位筆試的朋友一些參考。1. 這場筆試的整體畫像模塊分布與難度檔位先說結(jié)論這份卷子的難度屬于中等偏上但它的偏不在偏題怪題而在每一道題都往深處多問了一層。如果你只是把《數(shù)據(jù)庫系統(tǒng)概論》教材翻熟了大概能拿下基礎(chǔ)題但區(qū)分度最高的部分恰恰是那些看似見過、實(shí)則問法更刁鉆的題。從模塊分布來看我印象里整份卷子大致分為四塊模塊題型大致占比核心考察點(diǎn)概念與原理選擇題、判斷題30%事務(wù)隔離級別、索引結(jié)構(gòu)、日志機(jī)制、范式、鎖的類型SQL書寫手寫SQL30%多表關(guān)聯(lián)、分組聚合、窗口函數(shù)、增刪改查的邊界場景場景分析與優(yōu)化簡答、設(shè)計(jì)題30%慢SQL定位、索引優(yōu)化、死鎖排查、主從架構(gòu)設(shè)計(jì)生態(tài)與工具認(rèn)知選擇、簡答10%國產(chǎn)數(shù)據(jù)庫選型、同步工具、數(shù)據(jù)庫客戶端、向量數(shù)據(jù)庫等新方向時(shí)間上是90分鐘題量大概35到40道說實(shí)話不算寬裕。我自己的節(jié)奏是選擇題控制在25分鐘內(nèi)SQL題預(yù)留40分鐘剩下時(shí)間給場景大題最后10分鐘檢查。這個(gè)節(jié)奏在后半段還是有點(diǎn)緊尤其是有一道涉及多表關(guān)聯(lián)加窗口函數(shù)的SQL題我寫完之后反復(fù)驗(yàn)算了兩次才確信結(jié)果沒問題。如果說要給這批筆試定個(gè)性我的感受是它不考你知道什么而是考你用過之后理解了什么。比如它不會(huì)直接問什么是索引最左前綴原則而是給一張聯(lián)合索引表再給出三個(gè)查詢條件讓你判斷哪些能走索引、哪些不能并且要說明理由。這種出題方式對實(shí)操經(jīng)驗(yàn)的要求明顯高于對背誦的要求。難度檔位上我把它分成三檔基礎(chǔ)送分題大概占四成比如事務(wù)的ACID特性、B樹相比B樹的優(yōu)勢、普通索引和唯一索引的區(qū)別這些屬于復(fù)習(xí)過就能拿分中檔題占四成比如MVCC的快照讀和當(dāng)前讀區(qū)別、間隙鎖的作用范圍、一個(gè)慢SQL的完整優(yōu)化鏈路需要你真正理解原理才能答得完整剩下的兩成屬于拉開差距的題考察的是對數(shù)據(jù)庫生態(tài)的廣度認(rèn)知和架構(gòu)設(shè)計(jì)思維比如在一個(gè)高并發(fā)讀寫場景下如何選擇分庫分表方案、如何兼顧數(shù)據(jù)同步的實(shí)時(shí)性和一致性。這里要多說一句很多人在備戰(zhàn)數(shù)據(jù)庫崗筆試時(shí)容易陷入一個(gè)誤區(qū)只刷SQL題不碰原理。但我可以負(fù)責(zé)任地說這份卷子的SQL題只靠刷題能拿到的分很有限真正的重頭戲是把原理題答出深度。原理題考察的不光是記憶更是你是否踩過那些坑。比如它問為什么有時(shí)候表里明明有索引查詢卻依然很慢這種問題如果沒在真實(shí)環(huán)境里排查過慢SQL光靠背是答不出那個(gè)味兒的。2. SQL考察從增刪改查到慢查詢診斷考的不是語法而是思維這部分的題目雖然叫SQL書寫但它的考察重心絕對不止書寫本身。我印象最深的是它給了一個(gè)訂單表和商品表的業(yè)務(wù)場景要求統(tǒng)計(jì)每個(gè)品類銷量前3的商品這題一看就是要用窗口函數(shù)但它還埋了一個(gè)坑同一商品有多條記錄、同一訂單可能包含多個(gè)商品如果先關(guān)聯(lián)再排名結(jié)果就會(huì)因?yàn)榈芽柗e被放大。實(shí)際上這類題的正確解法是先按商品聚合銷量再在聚合結(jié)果上開窗排名。這種看起來是SQL題、其實(shí)考的是業(yè)務(wù)建模和去重思維的題在這份卷子里不止一道。所以我建議準(zhǔn)備這類筆試時(shí)每做一道SQL題都多問自己一句如果數(shù)據(jù)里有重復(fù)、有NULL、有關(guān)聯(lián)爆炸我的寫法還成立嗎2.1 聚合查詢的邊界條件GROUP BY相關(guān)的問題幾乎是必考的而且它特別喜歡在細(xì)節(jié)上做文章。這次筆試有一道題是統(tǒng)計(jì)每個(gè)用戶首次下單后的次日留存率很多人第一反應(yīng)是直接用JOIN兩次搞定但更嚴(yán)謹(jǐn)?shù)淖龇ㄊ窍扔么翱诤瘮?shù)ROW_NUMBER()把每個(gè)用戶最早的下單時(shí)間找出來再關(guān)聯(lián)第二天的活躍記錄。這兩種寫法在數(shù)據(jù)量小的時(shí)候結(jié)果都一樣但在真實(shí)的高并發(fā)業(yè)務(wù)庫里前者的執(zhí)行效率會(huì)差一個(gè)量級。還有一個(gè)經(jīng)典的坑SELECT子句里出現(xiàn)的非聚合列必須出現(xiàn)在GROUP BY里。但在某些數(shù)據(jù)庫的寬松模式比如MySQL的ONLY_FULL_GROUP_BY被關(guān)閉時(shí)下它不會(huì)報(bào)錯(cuò)卻會(huì)返回一個(gè)毫無意義的值。筆試?yán)锼赡懿粫?huì)直接考這個(gè)但它會(huì)換一種方式考給你一個(gè)查詢結(jié)果讓你判斷錯(cuò)誤原因。這時(shí)候就考驗(yàn)?zāi)銓QL標(biāo)準(zhǔn)與實(shí)際數(shù)據(jù)庫行為差異的熟悉程度了。2.2 增刪改查的高級變體增刪改查CRUD這個(gè)詞看起來基礎(chǔ)但筆試?yán)锏腃RUD很少有直接考單表插入和查詢的。它更常見的是讓你處理這些場景批量插入時(shí)如果主鍵或唯一索引沖突了是UPDATE還是忽略這就需要區(qū)分INSERT INTO ... ON DUPLICATE KEY UPDATE和INSERT IGNORE的語義差異。有一道題是要求把A表的數(shù)據(jù)同步到B表A表有新增也有更新。很多人寫的是先DELETE再INSERT但這樣會(huì)帶來自增ID變化和索引重建的開銷。更好的寫法是MERGE或等價(jià)的分兩步操作先更新已存在的記錄再插入不存在的記錄。關(guān)于UPDATE和DELETE的WHERE條件它專門出了一道題問如果一個(gè)UPDATE語句的WHERE條件里的子查詢跟目標(biāo)表是同一張表會(huì)不會(huì)報(bào)錯(cuò)這在MySQL里確實(shí)會(huì)有限制不能一邊查詢一邊更新同一張表解決辦法是包一層臨時(shí)表。這種題如果沒有實(shí)操經(jīng)驗(yàn)真的容易掉坑。2.3 窗口函數(shù)是必考項(xiàng)窗口函數(shù)大概是近幾年數(shù)據(jù)庫崗筆試?yán)锍鲧R率最高的知識點(diǎn)。這次卷子涉及到的窗口函數(shù)至少有ROW_NUMBER()、RANK()、DENSE_RANK()、SUM() OVER()這幾類。它考察的不僅是你會(huì)不會(huì)寫而是你知不知道它們之間的細(xì)微差別。比如RANK和DENSE_RANK在遇到并列排名時(shí)跳不跳號這決定了業(yè)務(wù)報(bào)表里的名次是否連續(xù)。我還遇到一道題問的是累計(jì)銷售額怎么算。累計(jì)值這個(gè)場景在日常寫SQL里太常見了很多人會(huì)想到用自連接去累加但效率很低實(shí)際上用SUM(amount) OVER (ORDER BY order_date)一行就能搞定。窗口函數(shù)在筆試中的高頻出現(xiàn)本質(zhì)上是考察你是否具備現(xiàn)代SQL的書寫意識畢竟在真實(shí)業(yè)務(wù)中窗口函數(shù)往往是處理每組取前N條計(jì)算移動(dòng)平均同比環(huán)比這類需求的最優(yōu)解。2.4 慢SQL診斷題從執(zhí)行計(jì)劃反推索引缺失這部分是我認(rèn)為整張卷子里最有實(shí)戰(zhàn)價(jià)值的一類題。它給了你在生產(chǎn)環(huán)境里常見的一個(gè)場景一張訂單表的數(shù)據(jù)量在千萬級某個(gè)分頁查詢越往后翻越慢讓你分析原因并給出優(yōu)化方案。這背后涉及的知識點(diǎn)是傳統(tǒng)LIMIT offset, size在大偏移量時(shí)需要掃描掉offset之前的行再丟棄成本極高。優(yōu)化思路一般有幾種延遲關(guān)聯(lián)先查出目標(biāo)頁的主鍵ID再回表關(guān)聯(lián)其他字段?；谟螛?biāo)的分頁用上一次查詢的最后一個(gè)ID作為下一次查詢的起點(diǎn)配合WHERE id ? LIMIT 10。覆蓋索引如果查詢列都包含在索引中就能避免回表。筆試?yán)镞€有一題給了帶EXPLAIN的輸出片段讓你指出其中的Using filesort、Using temporary、typeALL等關(guān)鍵詞分別代表什么問題。這里我要強(qiáng)調(diào)一個(gè)常見誤區(qū)很多人知道typeALL是全表掃描但不知道在什么情況下優(yōu)化器會(huì)放棄索引。比如對索引列做了函數(shù)運(yùn)算、隱式類型轉(zhuǎn)換、LIKE以通配符開頭、OR連接的非索引列條件、聯(lián)合索引不滿足最左前綴原則這些都會(huì)導(dǎo)致索引失效。這一類知識點(diǎn)在筆試?yán)飵缀跏撬头诸}但也是很多人考完對答案才發(fā)現(xiàn)自己錯(cuò)得離譜的地方。3. 事務(wù)、鎖與死鎖筆試?yán)镒羁简?yàn)底層理解的連環(huán)題如果說SQL題是送分題和拉分題的混合那事務(wù)與鎖相關(guān)的題目就是整張卷子的分水嶺。它考察的不再是你會(huì)不會(huì)寫SQL而是你知不知道數(shù)據(jù)庫在底層是怎么保證正確性的。這批筆試在這個(gè)模塊里出題非常密集從隔離級別到MVCC從行鎖到間隙鎖從死鎖日志到解決方案幾乎連成了一條完整的知識鏈。3.1 隔離級別的邊界場景事務(wù)隔離級別是必考的基礎(chǔ)題但它通常不會(huì)直接問四種隔離級別分別是什么而是給你一個(gè)具體的并發(fā)場景讓你判斷會(huì)出現(xiàn)什么問題。比如會(huì)話A開啟事務(wù)后更新了一行但未提交會(huì)話B此時(shí)讀這行數(shù)據(jù)在不同隔離級別下分別會(huì)讀到什么又比如會(huì)話A范圍查詢后會(huì)話B插入了一條新記錄那么在RR可重復(fù)讀和RC讀已提交隔離級別下會(huì)話A再次查詢會(huì)不會(huì)多出這條記錄幻讀這里有一個(gè)很多人容易忽略的點(diǎn)MySQL默認(rèn)的RR隔離級別理論上應(yīng)該存在幻讀問題但I(xiàn)nnoDB通過間隙鎖和MVCC的配合在特定條件下規(guī)避了幻讀。所以要答好這道題光背隔離級別的定義是不夠的還得理解它背后的實(shí)現(xiàn)機(jī)制。筆試?yán)锼踔羻柕搅丝煺兆x和當(dāng)前讀的區(qū)別普通的SELECT是快照讀不加鎖讀的是快照而SELECT ... FOR UPDATE、UPDATE、DELETE是當(dāng)前讀讀的是最新版本并加鎖。這個(gè)區(qū)分直接決定了你在RR級別下會(huì)不會(huì)觸發(fā)間隙鎖。3.2 MVCC的實(shí)現(xiàn)機(jī)制MVCC多版本并發(fā)控制是InnoDB實(shí)現(xiàn)高并發(fā)讀寫的核心機(jī)制也是筆試?yán)锏母哳l考點(diǎn)。它涉及到的幾個(gè)關(guān)鍵概念是隱藏字段DB_TRX_ID、DB_ROLL_PTR、undo log版本鏈、read view的生成規(guī)則。一個(gè)典型的題目是在RC和RR兩種隔離級別下同一個(gè)事務(wù)里兩次相同的SELECT是否結(jié)果一定一致考試?yán)锝o了一個(gè)三行數(shù)據(jù)的簡單表模擬兩個(gè)事務(wù)交叉執(zhí)行讓你判斷每次SELECT返回什么結(jié)果。這種題本質(zhì)上是考察你是否理解read view的生成時(shí)機(jī)。RC級別下每次SELECT都會(huì)生成新的read view所以可能會(huì)讀到其他事務(wù)已提交的數(shù)據(jù)RR級別下只在第一次SELECT時(shí)生成read view之后整個(gè)事務(wù)都用同一份快照。我當(dāng)時(shí)答這類題的方法是先把每個(gè)事務(wù)的執(zhí)行序列畫出來標(biāo)出每行數(shù)據(jù)在不同時(shí)刻的DB_TRX_ID然后逐一對應(yīng)read view的活躍事務(wù)列表去判斷可見性。這個(gè)過程在紙上花不了幾分鐘但能有效避免憑直覺作答的錯(cuò)誤。3.3 鎖的分類與加鎖規(guī)則關(guān)于鎖的題目主要有兩個(gè)方向一是鎖的類型與兼容性二是加鎖的范圍。前者包括共享鎖、排他鎖、意向鎖之間的兼容關(guān)系以及不同粒度鎖的沖突矩陣。后者是更重頭的考法給定一條SQL讓你判斷它會(huì)對哪些記錄加什么鎖。比如在RR隔離級別下SELECT * FROM t WHERE id 100 FOR UPDATE如果id上有主鍵索引它會(huì)對id100的所有記錄加行鎖同時(shí)對它們之間的間隙加間隙鎖next-key lock。如果where條件里的列沒有索引那問題就更復(fù)雜了InnoDB會(huì)對全表所有記錄加鎖因?yàn)榇藭r(shí)沒法精準(zhǔn)定位行。有一個(gè)容易被忽略的細(xì)節(jié)是間隙鎖只在RR級別下存在RC級別為了支持binlog格式的需要只加行鎖以及唯一索引等值查詢命中時(shí)不會(huì)加間隙鎖因?yàn)椴恍枰乐够米x。這些細(xì)節(jié)如果沒理解透遇到場景判斷題極易失分。3.4 死鎖的完整排查鏈路這部分是我在批筆試?yán)锓浅Ｏ矚g的一類題因?yàn)樗粫?huì)直接告訴你這倆事務(wù)會(huì)死鎖而是給你兩段并發(fā)執(zhí)行的事務(wù)語句和一張MySQL死鎖日志的片段讓你分析死鎖發(fā)生的原因和解決辦法。這種題非常貼近真實(shí)工作因?yàn)榫€上死鎖日志就是長那樣的。答題時(shí)我會(huì)按三步走第一步從日志中定位兩個(gè)事務(wù)各自持有的鎖和等待的鎖第二步畫出等待關(guān)系圖確認(rèn)是否存在循環(huán)等待第三步分析為什么會(huì)出現(xiàn)這種情況最后給出解決建議。需要提醒的是這道題的解決建議通常不是殺掉一個(gè)事務(wù)而是從業(yè)務(wù)或SQL設(shè)計(jì)層面優(yōu)化。常見的思路有調(diào)整事務(wù)內(nèi)SQL的執(zhí)行順序讓所有事務(wù)都按同一順序訪問資源減少事務(wù)持有鎖的時(shí)間在RR級別下盡量用RC級別優(yōu)化索引縮小加鎖范圍或者對熱點(diǎn)行做拆分降低并發(fā)沖突。這些建議我在實(shí)際工作中都驗(yàn)證過尤其是統(tǒng)一加鎖順序這一條在批量更新場景里幾乎能解決八成以上的死鎖問題。另外還有一道題提到了數(shù)據(jù)庫并發(fā)鎖和連接池之間的關(guān)系。它問的是當(dāng)連接池大小設(shè)置不當(dāng)、并發(fā)請求增多時(shí)為什么會(huì)出現(xiàn)線程阻塞和鎖等待時(shí)間變長。這個(gè)問題的本質(zhì)是連接池的大小決定了并發(fā)訪問數(shù)據(jù)庫的線程數(shù)如果連接數(shù)過大數(shù)據(jù)庫端鎖競爭加劇如果過小應(yīng)用端請求排隊(duì)。它考察的是你是否理解并發(fā)控制不只在數(shù)據(jù)庫內(nèi)部還在應(yīng)用和數(shù)據(jù)庫之間的連接管理層。4. 索引與執(zhí)行計(jì)劃從B樹到Explain為什么索引會(huì)失效索引模塊在這批筆試中的占比不低而且考法非常立體不是簡單問索引的作用是什么而是從數(shù)據(jù)結(jié)構(gòu)選型、索引失效場景、執(zhí)行計(jì)劃解讀三個(gè)層面來考察。這一部分我認(rèn)為是拿分性價(jià)比最高的模塊因?yàn)橹R點(diǎn)相對固定只要梳理清楚短時(shí)間內(nèi)就能提分。4.1 為什么是B樹關(guān)于索引結(jié)構(gòu)筆試?yán)锍霈F(xiàn)過一個(gè)經(jīng)典問題為什么InnoDB選擇B樹而不是B樹、紅黑樹或哈希表這道題的答題要點(diǎn)是B樹的所有數(shù)據(jù)都存儲(chǔ)在葉子節(jié)點(diǎn)并且葉子節(jié)點(diǎn)之間通過鏈表相連這帶來兩個(gè)優(yōu)勢——一是非葉子節(jié)點(diǎn)可以存放更多鍵值樹更矮更寬磁盤IO次數(shù)更少二是范圍查詢時(shí)可以直接沿葉子節(jié)點(diǎn)鏈表順序遍歷而不需要像B樹那樣在中序遍歷時(shí)回溯。哈希索引雖然單點(diǎn)查詢很快但不支持范圍查詢和排序所以只適合特定場景比如等值查詢極頻繁的緩存表。我在答題時(shí)還補(bǔ)充了一點(diǎn)InnoDB的主鍵索引是聚簇索引葉子節(jié)點(diǎn)直接存放整行數(shù)據(jù)而二級索引的葉子節(jié)點(diǎn)存放的是主鍵值所以通過二級索引查詢數(shù)據(jù)需要回表。這個(gè)聚簇索引與二級索引的區(qū)別在筆試?yán)飳?yīng)的一道題是為什么主鍵不宜過長因?yàn)橹麈I越長二級索引就會(huì)越大占用的存儲(chǔ)空間和IO成本都會(huì)上升。4.2 索引失效場景六個(gè)高頻考點(diǎn)索引失效是筆試中的?？徒衲赀@批也不例外。它給了一道復(fù)合索引(a, b, c)相關(guān)的題目判斷四條查詢是否命中索引。這背后是最左前綴原則但真正容易失分的是它結(jié)合了范圍查詢的右邊索引列會(huì)失效這個(gè)規(guī)則。比如WHERE a 1 AND b 10 AND c 5這個(gè)語句因?yàn)閎使用了范圍查詢c列就無法繼續(xù)用到索引了。除了這個(gè)還有幾個(gè)高頻失效場景需要熟記對索引列使用函數(shù)或表達(dá)式比如WHERE DATE(create_time) 2023-01-01這種情況應(yīng)該改成范圍查詢條件。隱式類型轉(zhuǎn)換比如varchar列用數(shù)字去匹配導(dǎo)致索引失效。LIKE以%開頭。使用OR連接條件時(shí)如果其中有一個(gè)列沒有索引整個(gè)查詢都可能走全表掃描。索引列允許為NULL時(shí)某些查詢條件下優(yōu)化器也可能放棄索引雖然這個(gè)沒有前幾個(gè)絕對但值得注意。我當(dāng)時(shí)做完這組題后最大的感受是光記住這些場景沒用還得理解優(yōu)化器做成本估算的邏輯。比如在數(shù)據(jù)量非常小的表里即便存在可用索引優(yōu)化器也可能選擇全表掃描因?yàn)樗浪闳頀呙韪?。這一點(diǎn)在筆試?yán)锊粫?huì)直接考但在執(zhí)行計(jì)劃題中如果出現(xiàn)typeALL和possible_keys非空的組合很多人就會(huì)卡住。4.3 執(zhí)行計(jì)劃解讀EXPLAIN里的關(guān)鍵字段Explain是分析SQL性能的核心工具筆試?yán)镉幸坏李}直接給出了一條慢查詢的EXPLAIN結(jié)果要求指出問題所在并給出優(yōu)化方案。我在實(shí)際工作中看執(zhí)行計(jì)劃一般按這個(gè)順序處理type至少要達(dá)到range級別最好能達(dá)到ref或const如果是ALL說明全表掃描這是第一個(gè)要優(yōu)化的大紅旗。key實(shí)際用到的索引是什么有沒有可能用了但不是最優(yōu)的。rows預(yù)估掃描行數(shù)如果這個(gè)數(shù)字跟實(shí)際返回的行數(shù)差距巨大說明統(tǒng)計(jì)信息可能過期或用錯(cuò)了索引。Extra有沒有Using filesort、Using temporary、Using index condition索引下推、Using index覆蓋索引。關(guān)于Using filesort它在筆試?yán)锏淖冃问荗RDER BY字段順序和聯(lián)合索引順序不一致時(shí)如何優(yōu)化。通常的解決思路是調(diào)整索引列順序讓排序字段也滿足最左前綴或者把排序和過濾結(jié)合起來創(chuàng)建聯(lián)合索引。但如果你的查詢里有范圍條件排序字段又在范圍條件之后那么排序依然會(huì)走filesort。這些細(xì)節(jié)看起來瑣碎卻是執(zhí)行計(jì)劃題答題是否完整的關(guān)鍵。4.4 覆蓋索引與索引下推覆蓋索引Using index和索引下推Using index condition是加分項(xiàng)但也是很多人答不全的知識點(diǎn)。覆蓋索引指的是SELECT的列都在索引中無需回表這在查詢列較少時(shí)能顯著提升性能。索引下推則是MySQL 5.6以后引入的優(yōu)化把WHERE條件中可以用索引列判斷的部分下推到存儲(chǔ)引擎層減少回表次數(shù)。有一道題我記得很清楚表t的聯(lián)合索引是(a, b)查詢條件是WHERE a 1 AND b LIKE x%SELECT出的列包含c。這道題的答案是a和b都能利用索引做定位和過濾但由于需要查c列還是需要回表同時(shí)b的LIKE條件可以在索引層通過索引下推完成過濾減少回表次數(shù)。這種題是一層層遞進(jìn)的答的時(shí)候最好把整個(gè)執(zhí)行鏈路講清楚而不是直接給結(jié)論。5. 從單機(jī)到架構(gòu)主從復(fù)制、讀寫分離與分庫分表的設(shè)計(jì)思維這批筆試的另一個(gè)出題方向是數(shù)據(jù)庫架構(gòu)設(shè)計(jì)。它沒有問純粹的八股概念而是把問題安插在業(yè)務(wù)場景中讓你在數(shù)據(jù)量變大、并發(fā)變高的前提下給出方案。這類題目沒有唯一標(biāo)準(zhǔn)答案但答題的框架和取舍思路是最重要的。5.1 主從復(fù)制與讀寫分離的取舍一道典型的題是一個(gè)讀多寫少的系統(tǒng)數(shù)據(jù)庫壓力大你打算引入一主兩從的架構(gòu)做讀寫分離請問需要考慮哪些問題這題考察的底層原理是binlog的復(fù)制機(jī)制。MySQL主從復(fù)制涉及binlog格式STATEMENT、ROW、MIXED的選擇從庫通過IO線程拉取主庫binlog再由SQL線程重放。這里面最容易出現(xiàn)的問題是從庫延遲。如果你在從庫上讀到的是幾秒之前的數(shù)據(jù)那么某些對數(shù)據(jù)一致性要求高的讀請求比如用戶剛下單后馬上查訂單就不能走從庫否則會(huì)出現(xiàn)讀不到自己寫的數(shù)據(jù)的尷尬。答題時(shí)我給出了三層優(yōu)化思路。第一層從SQL層面減少主庫壓力重要的讀走主庫可容忍延遲的讀走從庫第二層從架構(gòu)層面引入中間件如ProxySQL做讀寫分離的路由第三層如果有強(qiáng)一致需求考慮使用MySQL的半同步復(fù)制保證主庫在事務(wù)提交時(shí)至少有一個(gè)從庫收到了binlog。5.2 分庫分表的時(shí)機(jī)與策略另一道題是典型的千萬級數(shù)據(jù)、單表查詢變慢的場景問是否應(yīng)該分庫分表以及如何分。這題的關(guān)鍵是先判斷是否到了必須分庫分表的程度。通常單表數(shù)據(jù)量在兩千萬以下、索引合理時(shí)MySQL依然能保持較好的性能所以優(yōu)先考慮的應(yīng)該是索引優(yōu)化、歸檔冷數(shù)據(jù)、引入緩存。只有QPS和數(shù)據(jù)量都到了一定規(guī)模才需要分庫分表。如果真要分分表字段的選擇直接決定方案的成敗。它給了一個(gè)電商系統(tǒng)用戶訂單表按用戶ID分表就是常見做法因?yàn)橛脩舻牟樵兌际且杂脩魹橹行牡\(yùn)營側(cè)的跨用戶查詢就沒法走分表鍵需要引入?yún)R總表或搜索引擎。分庫分表還會(huì)帶來分布式ID、跨分片事務(wù)、數(shù)據(jù)遷移等問題回答時(shí)如果能提到用美團(tuán)Leaf或雪花算法生成分布式ID以及用ShardingSphere這類中間件做透明路由會(huì)顯得更有實(shí)戰(zhàn)經(jīng)驗(yàn)。5.3 數(shù)據(jù)庫同步工具與異構(gòu)數(shù)據(jù)遷移架構(gòu)題里還涉及了數(shù)據(jù)同步的內(nèi)容。比如主庫和從庫之間的同步、業(yè)務(wù)數(shù)據(jù)同步到數(shù)倉、或者M(jìn)ySQL同步到時(shí)序數(shù)據(jù)庫/TiDB等場景考察你對數(shù)據(jù)同步工具的了解程度。這里能說清楚全量同步和增量同步的區(qū)別以及增量同步中如何通過binlog訂閱比如Canal來捕獲數(shù)據(jù)變更會(huì)是很加分的回答。還有一道選擇題涉及數(shù)據(jù)庫同步軟件的功能邊界選項(xiàng)里出現(xiàn)了幾個(gè)工具考察的是你知不知道它們分別解決什么問題。有些是做實(shí)時(shí)增量同步的有些是做ETL批處理的有些是做跨機(jī)房雙向同步的。這類題不算難但如果你平時(shí)只用過Navicat或DataGrip做客戶端管理沒有接觸過同步工具可能就會(huì)丟分。5.4 SQLite與輕量級數(shù)據(jù)庫的筆試身影令人意外的是筆試?yán)镞€出現(xiàn)了一道關(guān)于SQLite的題考點(diǎn)是它的適用場景和限制。SQLite是典型的單文件數(shù)據(jù)庫在移動(dòng)端、嵌入式場景和本地工具里應(yīng)用廣泛但不適合高并發(fā)寫入。這題難度不大但它提醒我數(shù)據(jù)庫崗的考察面并不局限于MySQL和Oracle而是覆蓋了整個(gè)數(shù)據(jù)庫生態(tài)。跟SQLite類似的還有l(wèi)inux下的單文件數(shù)據(jù)庫相關(guān)熱詞這類輕量級數(shù)據(jù)庫在IoT和邊緣計(jì)算場景中常用。復(fù)習(xí)時(shí)對這些方向有個(gè)基本認(rèn)知就足夠應(yīng)付筆試不需要深挖。6. 技術(shù)棧廣度從Oracle到國產(chǎn)數(shù)據(jù)庫生態(tài)題比想象中更實(shí)如果你覺得數(shù)據(jù)庫崗筆試只考MySQL那就低估了出題人的布局。這批筆試的最后一類題目聚焦的是整個(gè)數(shù)據(jù)庫生態(tài)包括傳統(tǒng)商業(yè)數(shù)據(jù)庫、國產(chǎn)數(shù)據(jù)庫、數(shù)據(jù)庫工具鏈以及新興的向量數(shù)據(jù)庫和時(shí)序數(shù)據(jù)庫方向。這部分內(nèi)容占比不高但很能拉開分差因?yàn)樗姆e累更多來自日常接觸和行業(yè)關(guān)注度。6.1 Oracle與MySQL的習(xí)慣差異有一道題涉及Oracle和MySQL在SQL方言上的差異。比如Oracle里字符串拼接用||MySQL用CONCAT函數(shù)Oracle的分頁用ROWNUM或FETCH FIRSTMySQL用LIMITOracle的序列是顯式的SEQUENCEMySQL的自增列是AUTO_INCREMENT。如果只在MySQL環(huán)境下學(xué)習(xí)遇到這類題會(huì)有點(diǎn)懵。筆試?yán)镞€有一個(gè)關(guān)于Oracle數(shù)據(jù)庫安裝和配置的場景題其實(shí)考察的不是安裝步驟本身而是你對Oracle體系結(jié)構(gòu)的理解比如實(shí)例Instance和數(shù)據(jù)庫Database的區(qū)別SGA和PGA的作用redo log和undo表空間的設(shè)計(jì)。如果你在真實(shí)的項(xiàng)目里接觸過Oracle這些概念會(huì)非常熟悉。6.2 國產(chǎn)數(shù)據(jù)庫的崛起與選型邏輯國產(chǎn)數(shù)據(jù)庫是近年筆試熱點(diǎn)這批也不例外。它問的是在一個(gè)政企類項(xiàng)目中如果有自主可控的要求你會(huì)選擇哪款國產(chǎn)數(shù)據(jù)庫替代MySQL為什么這道題我完整寫了達(dá)夢數(shù)據(jù)庫和人大金倉兩個(gè)方向。達(dá)夢數(shù)據(jù)庫在架構(gòu)上對標(biāo)Oracle兼容性好適合從Oracle遷移的老系統(tǒng)人大金倉KingbaseES則對PostgreSQL和Oracle的兼容性都不錯(cuò)在信創(chuàng)項(xiàng)目中落地案例較多。同時(shí)我還提到了GaussDB在華為生態(tài)里的優(yōu)勢以及OceanBase、TiDB這類分布式數(shù)據(jù)庫在高并發(fā)場景下的選型思路。答題的核心邏輯不在于你背下了多少產(chǎn)品名而在于你是否有選型方法論。我給出的框架是先看兼容性從存量系統(tǒng)遷移的難易程度再看架構(gòu)集中式還是分布式然后看生態(tài)和社區(qū)活躍度最后結(jié)合團(tuán)隊(duì)的技術(shù)棧熟悉度做決策。框架比結(jié)論重要得多這也是面試官更希望看到的思維模式。6.3 數(shù)據(jù)庫工具鏈從dbx到Navicat筆試題里有一道選擇題涉及數(shù)據(jù)庫客戶端工具的功能對比。它是通過dbx數(shù)據(jù)庫工具這一類熱詞引申出來的考察你知不知道這些工具各有什么特點(diǎn)。dbx作為一個(gè)數(shù)據(jù)庫管理工具核心功能集中在連接管理、SQL編輯、數(shù)據(jù)導(dǎo)入導(dǎo)出等方面Navicat和DataGrip則是更常見的全平臺(tái)客戶端DBeaver在開源場景里使用率很高而命令行側(cè)的mysql-client和psql雖然不如圖形界面友好但在自動(dòng)化腳本和服務(wù)器上沒有圖形界面的環(huán)境里依然是首選。這類題本身不難但它背后反映出的信號是招聘方希望候選人不只是會(huì)用Navicat還要具備在多樣化工具鏈下工作的能力。對于筆試我建議你在簡歷里寫到的工具都親手操作一遍至少知道它支持哪些數(shù)據(jù)庫類型、大致的界面布局和核心功能入口這樣遇到工具類選擇題根本不用猜。6.4 向量數(shù)據(jù)庫與時(shí)序數(shù)據(jù)庫新方向進(jìn)入考綱向量數(shù)據(jù)庫相關(guān)的題目出現(xiàn)在這次筆試?yán)镒屛矣行┮馔獾屑?xì)一想又在情理之中。隨著大模型和RAG應(yīng)用的火熱向量數(shù)據(jù)庫的崗位需求在暴漲筆試中自然就多了向量檢索、相似度計(jì)算、Embedding存儲(chǔ)這類概念題。哪怕你目前的工作根本不涉及向量數(shù)據(jù)庫我也建議你對它的核心思想向量索引、近似最近鄰搜索、與關(guān)系型數(shù)據(jù)的結(jié)合方式有個(gè)基本認(rèn)知。時(shí)序數(shù)據(jù)庫也一樣它考察的是時(shí)序數(shù)據(jù)庫的數(shù)據(jù)庫結(jié)構(gòu)怎樣設(shè)計(jì)。熱詞里反復(fù)出現(xiàn)這個(gè)問題說明時(shí)序數(shù)據(jù)的場景監(jiān)控指標(biāo)、IoT傳感器、金融行情在業(yè)務(wù)中越來越普遍。時(shí)序數(shù)據(jù)庫的核心設(shè)計(jì)思路是按時(shí)間維度分區(qū)、數(shù)據(jù)壓縮率高、支持海量高并發(fā)寫入、聚合查詢能力強(qiáng)。如果你能答出這些特點(diǎn)和它與傳統(tǒng)關(guān)系型數(shù)據(jù)庫的差異在生態(tài)題上會(huì)非常加分。7. 備戰(zhàn)建議拿到一批筆試后的針對性復(fù)習(xí)路徑最后這部分不是總結(jié)是我自己從這次筆試?yán)锾釤挸鰜淼囊惶讖?fù)習(xí)方法算是給準(zhǔn)備春招的朋友一個(gè)參考方向。如果你手頭已經(jīng)拿到類似批次的筆試通知可以從以下幾個(gè)方面做重點(diǎn)投入性價(jià)比會(huì)非常高。第一SQL必須練到條件反射級別。筆試?yán)锏腟QL題不會(huì)給你太多思考時(shí)間尤其是窗口函數(shù)和多表關(guān)聯(lián)的組合題考場上臨時(shí)推演會(huì)很緊張。建議把力扣的數(shù)據(jù)庫題庫中等難度以上的題都刷一遍重點(diǎn)練窗口函數(shù)、連續(xù)性問題、分組TopN、留存率計(jì)算這幾類這些都是筆試?yán)锏某？汀５诙i和MVCC必須能用語言講出來。死記硬背最大的問題是遇到場景題你會(huì)發(fā)現(xiàn)知識點(diǎn)對不上號。我自己的方法是把事務(wù)并發(fā)問題當(dāng)成一個(gè)角色扮演游戲每次讀一條SQL就模擬一下InnoDB底層會(huì)加什么鎖、讀哪個(gè)版本、在什么條件下會(huì)不會(huì)阻塞。這個(gè)習(xí)慣堅(jiān)持兩三個(gè)星期應(yīng)對筆試?yán)锏逆i機(jī)制題就會(huì)輕松很多。第三執(zhí)行計(jì)劃必須親手看過。如果你沒有現(xiàn)成的慢SQL可以找一個(gè)線上或本地環(huán)境用EXPLAIN分析幾條不同寫法的查詢看看type、rows、Extra這些字段如何變化。看得多了筆試?yán)锝o出一條SQL的執(zhí)行計(jì)劃你就能一眼看出問題所在。第四對生態(tài)類題目的準(zhǔn)備不要過度焦慮。像向量數(shù)據(jù)庫、國產(chǎn)數(shù)據(jù)庫這類內(nèi)容做到知道是什么、能說出選型思路的程度就夠用了不需要花大量時(shí)間深入研究。真正的復(fù)習(xí)重心還是要放在SQL和原理題上這兩塊能保住80%的分?jǐn)?shù)。最后再分享一個(gè)我在考場上用的小技巧遇到拿不準(zhǔn)的場景判斷題先把題目里的隔離級別和索引情況圈出來再作答。很多看似復(fù)雜的并發(fā)題只要確定這兩個(gè)前提答案方向基本就不會(huì)跑偏?？荚囈埠米鲰?xiàng)目也罷數(shù)據(jù)庫崗拼到底的還是對底層機(jī)制的清晰認(rèn)知和對實(shí)際場景的準(zhǔn)確判斷。希望這份復(fù)盤對你有用。