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