簡介本資源為2025年第五屆全國大學生計算機系統(tǒng)能力大賽——OceanBase數(shù)據(jù)庫大賽官方配套技術(shù)資料包面向高校計算機及相關(guān)專業(yè)本科生聚焦數(shù)據(jù)庫內(nèi)核原理、分布式系統(tǒng)實踐與工程化開發(fā)能力培養(yǎng)。資源共2000個文件涵蓋468個C/C頭文件h/hxx/hpp與716個源碼文件cpp/cc/c支撐OceanBase核心模塊編譯與調(diào)試含133個Markdown文檔md提供賽題說明、環(huán)境搭建指南與API參考96個Python腳本py用于自動化測試與數(shù)據(jù)校驗另有大量JSON配置、YML部署模板、CMake構(gòu)建文件及測試用例in/expected/sample完整復(fù)現(xiàn)競賽開發(fā)與驗證閉環(huán)。壓縮包大小113.94MB目錄結(jié)構(gòu)層次清晰適合作為數(shù)據(jù)庫系統(tǒng)課程設(shè)計、畢業(yè)設(shè)計或競賽備賽的實戰(zhàn)基線代碼庫。目前已有49人學習下載可直接用于源碼閱讀、模塊修改、性能調(diào)優(yōu)與故障注入等深度實踐。1. 大賽概況一場面向數(shù)據(jù)庫內(nèi)核的硬核挑戰(zhàn)1.1 比賽是什么為什么值得打2025 全國大學生計算機系統(tǒng)能力大賽第五屆 OceanBase 數(shù)據(jù)庫大賽本質(zhì)上是給在校學生準備的一場數(shù)據(jù)庫內(nèi)核實戰(zhàn)訓練營。主辦方把 OceanBase 這個成熟分布式數(shù)據(jù)庫的源碼和測試框架交到你手里讓你在有限時間內(nèi)完成指定的功能開發(fā)或性能優(yōu)化任務(wù)最后用系統(tǒng)跑分和代碼質(zhì)量說話。這個比賽和常見的背八股競賽完全不同。你寫的是要真正跑起來的存儲、事務(wù)、SQL 引擎代碼不是提交一份設(shè)計方案。對我來說它最吸引人的地方在于這是少數(shù)幾個能在學生階段直接接觸工業(yè)級數(shù)據(jù)庫源碼的窗口。OceanBase 的代碼量級、工程規(guī)范、模塊設(shè)計和你在課本里看的教學數(shù)據(jù)庫完全是兩回事。哪怕最后沒拿獎把源碼啃一遍對數(shù)據(jù)庫的理解深度都會上一個臺階。適合誰來打我的判斷是計算機、軟件工程相關(guān)專業(yè)學過數(shù)據(jù)庫原理和操作系統(tǒng)至少熟悉 C 或 Rust 中一門同時對分布式系統(tǒng)有好奇心的人。如果你只寫過業(yè)務(wù) CRUD沒碰過系統(tǒng)級代碼這個比賽會有點吃力但也不是完全沒法打——前提是你愿意花時間補基礎(chǔ)。反過來如果你已經(jīng)對 LSM-Tree、MVCC、兩階段提交這些概念有基本認識那這個比賽就是你把理論變成代碼的最佳實驗場。1.2 賽制與評分機制解讀賽制通常分初賽和決賽兩個階段。初賽以線上提交代碼、系統(tǒng)自動評測為主。評測維度一般包括功能正確性、性能指標、資源占用等指標。題目會在賽前公布選手需要在規(guī)定時間內(nèi)完成代碼修改并提交系統(tǒng)會對你的實現(xiàn)跑測試用例給出一份實時排名。決賽通常是線下答辯加現(xiàn)場優(yōu)化除了跑分還要講清楚設(shè)計思路和優(yōu)化手段。我特別提醒第一次參賽的朋友注意一個點初賽排名不是只看最終跑分很多時候還有最小提交間隔代碼評審之類的軟性約束。這意味著你不能只在最后一天堆代碼。系統(tǒng)對提交次數(shù)也可能有限制亂提交刷分會直接扣分甚至取消資格。建議把提交當作一種有限的評測資源來管理想清楚了再提交。評分機制背后的核心邏輯是考驗?zāi)阍诠こ碳s束下做權(quán)衡的能力。OceanBase 的代碼已經(jīng)很成熟了你做的修改必須既有正確性又不能破壞原有架構(gòu)的穩(wěn)定性。也就是說粗暴的魔改可能會在某個性能指標上拿了高分但代碼評審一關(guān)就被打回去。這種系統(tǒng)思維工程規(guī)范的考核方式也是它能進入計算機系統(tǒng)能力大賽序列的根本原因。1.3 和其他數(shù)據(jù)庫比賽的橫向?qū)Ρ仁忻嫔蠑?shù)據(jù)庫類比賽不少有的側(cè)重 TiDB、有的側(cè)重大數(shù)據(jù)組件但 OceanBase 大賽有幾個明顯特點。第一它強調(diào)內(nèi)核開發(fā)不是簡單的調(diào)參比賽。第二它提供了完整的源碼環(huán)境和調(diào)試工具鏈等于把生產(chǎn)級代碼庫開放給你們。第三OceanBase 同時兼容 MySQL 和 Oracle 兩種模式意味著你要處理的問題覆蓋面很廣從 SQL 語法解析到事務(wù)隔離級別都可能踩到。我對比過其他同類賽事很多比賽更像填空題——在給定的幾個函數(shù)里補全邏輯跑通就完事。OceanBase 大賽更像項目制開發(fā)你需要自己定位問題、設(shè)計解法、驗證效果。這種開放性對初學者來說門檻更高但對真正想往數(shù)據(jù)庫內(nèi)核方向走的人反而是最有價值的訓練。備賽過程中接觸到的模塊劃分、日志系統(tǒng)、測試框架都是可以直接寫進簡歷的經(jīng)驗。2. 核心考察點拆解你會在哪些模塊上做文章2.1 SQL 引擎從解析到執(zhí)行的完整鏈路SQL 引擎是初賽題目的高頻出題點。它的基本鏈路是客戶端輸入 SQL經(jīng)過詞法分析、語法分析生成邏輯計劃再經(jīng)過優(yōu)化器生成物理計劃最后交給執(zhí)行器去跑。OceanBase 的 SQL 引擎同時支持 MySQL 和 Oracle 模式所以你會看到大量兼容性相關(guān)的邏輯比如兩種模式下日期函數(shù)的行為差異、字符串排序規(guī)則、隱式類型轉(zhuǎn)換規(guī)則等。如果你在備賽時接到這類題目我建議先花時間看懂三塊代碼SQL 解析器的語法文件通常用 yacc 語法描述、優(yōu)化器的規(guī)則框架、執(zhí)行器的算子實現(xiàn)。不用全部吃透但要搞清楚一條 SQL 從進入到返回結(jié)果需要經(jīng)過哪些核心類。實際操作中你可以在代碼里加日志跑幾條簡單 SQL把流程打印出來對著看比悶頭讀代碼快得多。2.2 存儲引擎LSM-Tree 與數(shù)據(jù)落盤機制存儲引擎是 OceanBase 最核心的模塊之一。它采用 LSM-Tree 架構(gòu)寫入先進內(nèi)存中的 MemTable達到閾值后凍結(jié)、轉(zhuǎn)儲到 SSTable后臺再定期做 compaction 合并。這套機制決定了數(shù)據(jù)庫的寫性能也帶來了讀放大的問題——一次讀取可能要查多個 SSTable所以你需要理解布隆過濾器、索引、塊緩存這些配套機制是怎么工作的。從比賽角度存儲引擎常見的優(yōu)化方向包括調(diào)整 compaction 觸發(fā)策略、優(yōu)化編碼壓縮算法、改進掃描性能、減少空間放大等。我記得有一年賽題跟合并minor merge策略有關(guān)需要在性能和穩(wěn)定性之間做取舍。這類題目如果你不了解 LSM-Tree 的原理很容易拿著表面參數(shù)亂調(diào)效果大概率適得其反。我的建議是先把《數(shù)據(jù)庫系統(tǒng)實現(xiàn)》和《Designing Data-Intensive Applications》里關(guān)于 LSM 的章節(jié)吃透再動手改代碼。2.3 事務(wù)處理與并發(fā)控制隔離級別、鎖與分布式事務(wù)事務(wù)模塊是拉開差距的地方。OceanBase 實現(xiàn)了多種隔離級別包括 MySQL 模式下的可重復(fù)讀、Oracle 模式下的已提交讀。它采用 MVCC鎖的混合方案讀操作走快照寫操作需要加鎖。還有一套分布式事務(wù)處理框架用兩階段提交保證跨節(jié)點事務(wù)的原子性。這里的考察點可能是某個隔離級別下的事務(wù)并發(fā)行為異常需要你修復(fù)隔離性漏洞也可能是某個鎖等待場景出現(xiàn)死鎖需要你優(yōu)化加鎖順序甚至可能是分布式事務(wù)提交效率太低需要你優(yōu)化協(xié)調(diào)者邏輯。無論哪種你都得先建立起事務(wù)并發(fā)控制的整體心智模型。否則你看代碼就像看天書。我建議備賽時畫一張狀態(tài)圖把事務(wù)從開始到提交/回滾的所有狀態(tài)轉(zhuǎn)換、鎖獲取時機、版本可見性判斷條件列出來后面所有問題都往這張圖上套。2.4 性能優(yōu)化與資源管理內(nèi)存、線程、緩存除了功能開發(fā)性能評測也是重頭戲。性能優(yōu)化不像功能題那樣有一條明確的對錯線它更考驗?zāi)銓ο到y(tǒng)瓶頸的敏感度。常見的性能優(yōu)化方向包括內(nèi)存分配器調(diào)優(yōu)、線程池參數(shù)調(diào)整、緩存命中率優(yōu)化、SQL 執(zhí)行計劃優(yōu)化等。這里有個容易踩的坑很多同學一上來就在代碼里加各種花哨的優(yōu)化結(jié)果 benchmark 數(shù)據(jù)反而更難看了。因為現(xiàn)代 CPU 架構(gòu)下性能問題往往出在緩存失效、偽共享、鎖競爭這些底層因素而不是算法本身。我見過有選手為了優(yōu)化一個查詢重寫了排序算法結(jié)果因為引入了額外的內(nèi)存拷貝吞吐量反而下降 20%。性能優(yōu)化一定要用 profiler 說話不要靠猜。OceanBase 的代碼庫本身帶了一些性能統(tǒng)計工具評測環(huán)境也會提供 profile 結(jié)果你要學會看這些數(shù)據(jù)找瓶頸。3. 實操過程從零到提交一份靠譜的作品3.1 環(huán)境準備與工具鏈搭建拿到題目第一步先把環(huán)境搭起來。OceanBase 的部署不復(fù)雜但有一些細節(jié)需要注意。建議直接用官方提供的 OceanBase DeployerOBD工具部署一個單機版實例然后在同一臺機器上準備好源碼編譯環(huán)境。有一個容易忽略的點是依賴庫版本比如 libaio、numactl、jemalloc 這些版本不對可能導致編譯失敗或運行時性能異常。調(diào)試工具鏈里我重點推薦三樣GDB多線程調(diào)試必備、Perf性能采樣、以及 dtrace 或 bpftrace如果你在 Linux 上跑。比賽過程中你可能要排查各種詭異的并發(fā)問題沒有這幾個工具會很痛苦。代碼閱讀工具的話我習慣用 VS Code 或者 CLion但說實話OceanBase 的代碼規(guī)模用 IDE 打開會有點卡建議把代碼索引打開然后搭配 grep 和 ctags 快速定位符號。環(huán)境搭好之后運行自帶的測試套件確?；€是綠的通過狀態(tài)。這一條太重要了。我見過太多選手沒跑基線就跑題結(jié)果環(huán)境問題被當成代碼問題排查了幾天。基線綠了之后再開始看題這是最穩(wěn)妥的節(jié)奏。3.2 源碼閱讀路徑與模塊定位方法OceanBase 的源碼目錄劃分清晰你需要把主要的模塊目錄記下來。比如 observer 目錄是數(shù)據(jù)庫主進程代碼storage 目錄是存儲引擎sql 目錄是 SQL 引擎transaction 目錄是事務(wù)模塊share 目錄是共享組件等。拿到題目后第一件事就是判斷它命中哪個模塊然后快速鎖定代碼范圍。我自己的經(jīng)驗是三步走定位代碼第一步用題目里的關(guān)鍵詞在代碼庫全局搜索比如題目出現(xiàn)了轉(zhuǎn)儲就搜 minor freeze、major freeze、sstable dump 這些相關(guān)關(guān)鍵詞第二步跑一個最小復(fù)現(xiàn)用例打斷點或者加日志看代碼執(zhí)行路徑第三步從入口函數(shù)往調(diào)用棧下層走逐步縮小問題范圍。這個方法比逐行通讀源碼高效得多。有一種情況比較麻煩題目涉及跨模塊調(diào)用。比如一個 SQL 性能問題根因可能在存儲層也可能在執(zhí)行器層還可能是優(yōu)化器生成了糟糕的執(zhí)行計劃。這種問題要在多個模塊之間來回跳容易迷路。我的建議是先在紙上畫出調(diào)用鏈的大致走向確認所有涉及模塊的入口和出口再逐層排查。千萬別拿著代碼瞎轉(zhuǎn)效率極低。3.3 一個具體題目從分析到落地的全流程示例我以一道模擬題為例詳細講講整個流程實際比賽題目結(jié)構(gòu)類似但具體細節(jié)不同。假設(shè)題目是優(yōu)化一條包含多表 JOIN 的查詢在特定數(shù)據(jù)集上的執(zhí)行性能要求在保證結(jié)果正確的前提下盡量縮短查詢響應(yīng)時間。第一步定位。在 SQL 引擎層跑這條查詢用 EXPLAIN 拿到執(zhí)行計劃看看表連接順序、連接算法、是否走索引。如果發(fā)現(xiàn)是嵌套循環(huán)連接且一張表很大一張表很小那就應(yīng)該改為哈希連接。但 OceanBase 的優(yōu)化器不一定總能做出最優(yōu)選擇有時候要用 hint 強制改變執(zhí)行計劃。第二步驗證假設(shè)。手動改寫 SQL 加 hint跑一遍看時間是否縮短。如果明顯縮短說明優(yōu)化器選型確實有問題需要到優(yōu)化器代碼里找原因?？赡苁墙y(tǒng)計信息不準導致基數(shù)估計偏差很大也可能是 cost model 的權(quán)重參數(shù)設(shè)置不合理。第三步修改代碼。如果問題在統(tǒng)計信息可以看看表統(tǒng)計信息更新的觸發(fā)條件和采樣策略。如果問題在 cost model找到算子代價計算的函數(shù)調(diào)整相應(yīng)權(quán)重。這個階段要注意改動越局部越好不要牽一發(fā)動全身。第四步回歸測試。跑功能的測試用例確保正確性不受影響。再跑性能測試對比修改前后的耗時。最后在正式評測環(huán)境提交前再做幾輪壓力測試確認沒有內(nèi)存泄漏、并發(fā)問題等隱患。整個流程走下來你會發(fā)現(xiàn)真正的挑戰(zhàn)不是某一環(huán)而是如何快速定位問題、驗證假設(shè)、控制變更風險。這正是比賽最有收獲的部分。3.4 性能調(diào)優(yōu)的常用工具與指標判讀性能調(diào)優(yōu)階段我會用 perf 做 CPU 熱點采樣用 OceanBase 自帶的內(nèi)部視圖查等待事件、緩存命中率等指標。舉幾個關(guān)鍵指標的例子緩存命中率如果低于 95%可能說明表數(shù)據(jù)量太大而緩存太小L0/L1 層 SSTable 數(shù)量過多可能導致讀放大嚴重memstore 內(nèi)存使用超過閾值可能導致寫入停滯。我還習慣在代碼里臨時加一些計數(shù)器和耗時埋點比如統(tǒng)計一次查詢在解析、優(yōu)化、執(zhí)行各階段分別花了多少時間。注意這些埋點代碼提交前一定要清理干凈否則評測系統(tǒng)可能因為額外的開銷導致分數(shù)下降甚至有作弊嫌疑。優(yōu)化是迭代過程每次只改一個變量跑一輪測試記錄結(jié)果再改下一個。一次性改多個變量出了問題你根本不知道是哪個改動引起的。4. 備賽路上的常見問題和實用解決技巧4.1 編譯環(huán)境問題和依賴版本沖突怎么解決編譯 OceanBase 源碼可能是很多人遇到的第一個坎。官方文檔給的依賴列表是最低要求實際操作中你會發(fā)現(xiàn)各發(fā)行版系統(tǒng)的包管理器里的版本可能不夠用。比如 glibc 版本太老編譯時直接報錯jemalloc 版本不一致運行時就出現(xiàn)詭異的內(nèi)存問題。我踩過一次很深的坑在官方推薦的 Linux 發(fā)行版上用系統(tǒng)自帶的 gcc 編譯鏈接階段報了一堆 undefined reference。后來發(fā)現(xiàn)是編譯器版本太舊不支持代碼里用到的一些新特性。解決辦法是換用官方提供的 devtoolset 或者手動安裝新版 gcc。還有一次是編譯通過但運行時崩潰排查了大半天發(fā)現(xiàn)是系統(tǒng)字符集設(shè)置問題和代碼沒有任何關(guān)系。所以建議是嚴格按照官方文檔的發(fā)行版版本來搭建環(huán)境不要自創(chuàng)環(huán)境不要用太新的內(nèi)核和編譯器組合也不要為了追求性能而加亂七八糟的編譯參數(shù)。穩(wěn)定的環(huán)境比炫技重要得多。4.2 性能優(yōu)化的常見誤區(qū)和評測環(huán)境陷阱性能優(yōu)化最大的誤區(qū)是用感覺代替測量。有人覺得某個熱點函數(shù)用了內(nèi)存拷貝就一定要優(yōu)化但實測發(fā)現(xiàn)它根本不是瓶頸有人覺得多線程就能提性能結(jié)果線程切換開銷抵消了收益。我建議所有優(yōu)化都圍繞 profiler 數(shù)據(jù)展開量化每一步的收益不要做沒有數(shù)據(jù)支撐的盲改。評測環(huán)境的另一個陷阱是你的代碼在本地跑得很快不代表在評測機上也快。評測機可能有不同的 CPU 頻率、核數(shù)、內(nèi)存帶寬還有與其他選手共享資源的可能。所以寫完代碼后盡量在接近評測環(huán)境的條件下測試比如限制 CPU 核數(shù)、內(nèi)存大小等。我曾在本地 16 核機器上調(diào)優(yōu)到一個不錯的效果換了評測機 8 核環(huán)境就跑不過別人原因是我沒考慮核數(shù)變化對線程池并發(fā)度的影響。這些都是需要在備賽時就考慮到的。4.3 遇到死鎖、數(shù)據(jù)不一致等疑難 bug 時怎么辦這類問題最熬人但也最漲經(jīng)驗。我的調(diào)試方法是三板斧第一步復(fù)現(xiàn)問題拿到穩(wěn)定復(fù)現(xiàn)的最小用例第二步打開日志和 trace盡量定位到觸發(fā)路徑第三步用 GDB 附加到進程在關(guān)鍵函數(shù)下斷點單步調(diào)試或觀察變量快照。如果能在測試環(huán)境穩(wěn)定復(fù)現(xiàn)問題基本都能解決最怕的是偶現(xiàn)問題那種只能靠日志和概率復(fù)現(xiàn)慢慢磨。調(diào)試死鎖時有一個技巧在鎖獲取的地方打印線程 ID、鎖地址和持有時間跑一段時間后分析日志就能畫出鎖等待圖。定位到環(huán)之后再想想為什么會出現(xiàn)環(huán)是鎖順序不一致還是鎖粒度太大。數(shù)據(jù)庫里的死鎖很多時候和事務(wù)加鎖順序有關(guān)你要結(jié)合事務(wù)執(zhí)行計劃分析加鎖邏輯。這里有個經(jīng)驗之談在代碼里加上鎖順序的斷言開發(fā)階段就能發(fā)現(xiàn)大部分問題比運行時報死鎖再處理效率高得多。4.4 常見問題速查表問題現(xiàn)象可能原因排查手段編譯鏈接失敗編譯器版本過舊 / 依賴庫缺失檢查 gcc 版本、安裝完整依賴、查看 CMake 日志部署后實例啟動失敗配置參數(shù)錯誤 / 端口被占用查看 observer.log、確認端口占用、核對配置項性能評測分數(shù)低線程池配置不當 / 緩存命中率低用 perf 采樣、查內(nèi)部視圖指標、調(diào)整參數(shù)偶現(xiàn)崩潰內(nèi)存越界 / 多線程數(shù)據(jù)競爭用 ASAN 編譯、加日志復(fù)現(xiàn)、GDB 分析 core 文件查詢結(jié)果錯誤優(yōu)化器選型錯誤 / 并行執(zhí)行問題對比 EXPLAIN 計劃、關(guān)閉并行重跑、逐算子驗證死鎖加鎖順序不一致 / 隔離級別設(shè)置異常分析鎖等待日志、檢查事務(wù)加鎖路徑這張表不是標準答案但它可能是比賽過程中最常見的六大問題方向。你還會遇到更奇怪的 bug但思路是一致的縮小范圍、穩(wěn)定復(fù)現(xiàn)、分而治之。5. 復(fù)盤與個人建議5.1 參賽帶來的收獲不只是代碼能力打完這個比賽我的一個深刻感受是寫業(yè)務(wù)代碼和寫數(shù)據(jù)庫內(nèi)核代碼是完全不同的思維方式。業(yè)務(wù)代碼講究快速迭代而內(nèi)核代碼追求的是極端條件下的穩(wěn)定性和可預(yù)測性。你會開始關(guān)注一個整數(shù)溢出會不會被惡意構(gòu)造的 SQL 觸發(fā)、一個并發(fā)場景下會不會出現(xiàn) ABA 問題、一個緩存未命中會讓性能下降多少倍。這些細節(jié)意識是日常開發(fā)很難鍛煉出來的。數(shù)據(jù)庫內(nèi)核圈子里有一句話懂數(shù)據(jù)庫原理的人很多但真正改過數(shù)據(jù)庫的人很少。在 OceanBase 大賽的經(jīng)歷相當于把數(shù)據(jù)庫原理從概念變成了你親手敲過、調(diào)試過、性能調(diào)優(yōu)過的代碼。面試時你能聊的東西完全不是一個層次。好多拿了名次的選手后來都進入了數(shù)據(jù)庫或基礎(chǔ)軟件相關(guān)的團隊這條路確實走得通。5.2 適合在比賽前掌握的知識清單如果你是零基礎(chǔ)沖比賽的選手我的建議是先把這些知識過一遍再動手寫代碼數(shù)據(jù)結(jié)構(gòu)與算法基礎(chǔ)B 樹、跳表、哈希表、排序、歸并等。操作系統(tǒng)進程與線程、內(nèi)存管理、文件 IO、鎖與條件變量。數(shù)據(jù)庫原理SQL 執(zhí)行流程、事務(wù) ACID、隔離級別、MVCC、鎖機制、日志與恢復(fù)。分布式系統(tǒng)基礎(chǔ)一致性、兩階段提交、Paxos/Raft 的工程實現(xiàn)。C 語言特性智能指針、模板、右值引用、并發(fā)編程。這些知識不需要全部精通但至少要達到看到代碼能認出它在干什么的程度。在此基礎(chǔ)上再啃 OceanBase 的核心源碼就順很多。你也可以先跑一遍 OceanBase 官方的開發(fā)者文檔和入門教程特別是部署、SQL 基本操作、存儲架構(gòu)這些章節(jié)。把理論模型先建立起來再深入代碼細節(jié)比我一開始就投身源碼、看得云里霧里要高效得多。我的個人教訓是第一次接觸時我太著急了直接去讀底層存儲代碼結(jié)果各種術(shù)語和概念根本對不上號。后來老老實實按文檔從整體架構(gòu)入手再回頭看代碼一下子通透了。5.3 未來的擴展方向比賽結(jié)束后如果你對這個方向還有興趣可以繼續(xù)研究一下 OceanBase 的社區(qū)版源碼看看最新版本里引入了哪些新特性。也可以嘗試復(fù)現(xiàn)一些數(shù)據(jù)庫論文中的算法比如更高效的 compaction 策略、更智能的索引推薦、KV 分離存儲等?；A(chǔ)軟件這個領(lǐng)域動手實踐是遞進式進步的源泉。一臺機器、一個開源數(shù)據(jù)庫、加上一點耐心和死磕精神就能做出很漂亮的項目。這也是我這些年做技術(shù)一路走下來感受最深的一點。本文還有配套的精品資源點擊獲取