本文摘自《OceanBase社區版在泛互場景的應用案例研究》電子書，點擊鏈接獲取完整版內容。

作者：高山岩，OceanBase資深技術專家

海量數據日益增長的今天，越來越多的業務系統面臨高併發、高性能訪問的壓力，以至於企業對業務系統的性能保障訴求越來越強烈。數據庫系統作為業務系統的基礎組件，具備高併發、高性能的能力，是支撐業務系統、滿足客户訴求的關鍵。本文通過闡述數據庫組件的設計，解讀做好系統性能保障的關鍵因素。

通過內核組件的合理設計，保障系統性能

作為連續12年保障“天貓雙11”大促活動以及用於支付寶核心系統的數據庫，OceanBase久經高併發場景的多重性能考驗。2025年3月，OceanBase性能再次升級，在同等的硬件規模下（16 核配置），經過 Sysbench 標準測試集的實際測試（見圖1），其單機版在整體性能（包括查詢、批量讀取、寫入、讀寫混合、插入和更新操作）方面全面優於 MySQL 8.0。特別是在高併發寫入場景中，吞吐量實現了顯著提升，最高提升達到 214.99%，能夠滿足高負載場景下的業務需求。

圖1 Sysbench 性能基準測試對比（OceanBase 單機版VS MySQL 8.0）

OceanBase的高性能離不開系統內核各個組件的設計與實現，主要包含高效的計劃管理、併發控制、多維度緩存優化、熱點行優化、日誌聚合優化和編譯優化等方面。下文將分別解析各模塊，為大家揭開高性能的神秘面紗。

（一）高效的計劃管理

1.計劃緩存。

SQL語句的優化是一個比較耗時的過程，隨着SQL語句的複雜度增高，優化的時間也會越來越長。為了避免反覆執行優化過程，生成的執行計劃會加入計劃緩存中，以便再次執行該SQL時使用。每一個租户在每一台server上都有一個獨立的計劃緩存，用以緩存在此server上處理過的SQL計劃。

在應用系統中，同一條SQL每次執行可能會使用不同的參數，為了減少計劃緩存的大小，系統會首先將用户SQL的參數做參數化處理，得到與具體參數無關的SQL字符串，並使用該字符串作為計劃緩存的鍵值。計劃緩存是一個典型的Key-Value結構，Key就是參數化後的SQL字符串，Value就是該條SQL所對應的執行計劃。在OceanBase的計劃緩存中，SQL的執行計劃可以分為本地計劃、遠程計劃和分佈式計劃三種類型。在計劃緩存中，同一條SQL根據其需要訪問的數據不同，可能同時有這三種執行計劃。對於某一條SQL的某一種執行計劃，默認情況下OceanBase只會保留一個計劃，該計劃由第一次執行SQL時生成；但在某些情況下，同一條SQL的參數值可能會影響到計劃的選擇，計劃緩存可能會根據需要，為不同的參數值保留不同的執行計劃，從而保證每次執行時可以使用最合適的計劃。

2.快速參數化。

有了計劃緩存之後，如何快速獲取緩存數據，是需要考慮的另一個問題。傳統數據庫在進行參數化時一般是對語法樹進行參數化，然後使用參數化後的語法樹作為鍵值在Plan Cache中獲取計劃，而OceanBase使用的是詞法分析，對文本串直接參數化後作為Plan Cache的鍵值，因此叫做快速參數化。具體流程如圖2所示。

圖2 基於快速參數化的獲取執行計劃過程

計劃緩存的優化，減少了計劃生成的重複動作。快速參數化，省去了語法分析的過程，與此同時，相比對參數化後語法樹做Hash和比較操作，對文本串進行Hash和MemCmp操作，效率更高，提升了從計劃緩存中獲取計劃的效率。兩個優化本質上均降低了CPU的開銷，從而提升系統的吞吐能力。

（二）併發控制

1.數據管理。

OceanBase 存儲引擎採用的是 LSM tree 架構，數據分成靜態和動態數據。動態數據保存在 Memtable 中並定期 dump 到磁盤中，Memtable 採用 B+tree 以及Hash 雙索引結構對數據進行存儲，其中 B+tree 用於範圍查詢，Hash 用於單行查詢。B+tree 的葉子節點保存了行數據的元信息，關鍵的3個字段：主鍵、鎖以及鏈表指針，如圖3所示。

圖3 memtable內存數據結構圖（行上的多次修改）

• 鎖信息表示是否有事務持有行鎖，事務在修改數據之前需要先加行鎖。
• 鏈表信息指向多個版本的數據，每個版本只保存增量信息，比如某一次修改只修改一個字段，增量信息只會記錄該字段的變化情況。
• 對於尚未提交，已經轉儲到靜態數據中的行，靜態數據會進行特殊標記，用於行鎖存在與否的判斷。

2.併發控制。

OceanBase 基於MVCC和行上的互斥鎖，實現了併發控制，主要特點如下：

• 快照版本一個時間戳，通過比較時間戳的大小就可以確定事務的可見性。因此，相比其他數據庫系統，OceanBase不需要維護全局事務管理器，高併發場景下，不存在全局事務管理器訪問瓶頸的問題。
• OceanBase 行的元數據上保存了鎖信息，同樣也不需要額外的鎖管理器。
• 讀操不加行鎖，寫操作加行上的互斥鎖，做到了讀、寫不相互阻塞，提升了高併發場景下的吞吐。

圖4 memtable內存數據結構圖（讀寫請求邏輯）

（三）多維度緩存

上文提到，OceanBase 存儲引擎採用的是 LSM tree 架構，其存儲引擎整體架構如圖5所示。

圖5 OceanBase存儲引擎架構圖

通常來講，LSM架構的查詢，需要將靜態數據和動態數據做merge，經過投影之後再返回給客户端。對於多級的sstable，這無疑會增加執行路徑。為了提升查詢效率，OceanBase設計多級緩存策略，具體包括以下5項。

（1）Block Cache：類似於Oracle的Buffer Cache，緩存具體的數據塊，實際上Block Cache中緩存是解壓後的微塊，大小是變長的。

（2）Block Index Cache：緩存微塊的索引，類似於Btree的中間層，在數據結構上和Block Cache有一些區別，由於中間層通常不大，Block Index Cache的命中率通常都比較高。

（3）BloomFilter Cache：BloomFilter是一種結構，可以幫助加速對空查詢的過濾，有助於提升insert的性能。OceanBase的BloomFilter是構建在宏塊上的，按需自動構建，當一個宏塊上的空查次數超過某個閾值時，就會自動構建BloomFilter，並將BloomFilter放入Cache。

（4）Row Cache：Row Cache緩存具體的數據行，在進行Get/MultiGet查詢時，可能會將對應查到的數據行放入Row Cache，這樣在進行熱點行的查詢時，就可以極大地提升查詢性能。

（5）Fuse Row Cache：跟row cache的差異在於，fuse row cache緩存的是當前系統中動、靜態數據merge之後的值，對於高頻的數據訪問，可以直接訪問fuse row cache；

（四）熱點行優化

隨着在線交易、電商行業的發展，業務系統的熱點併發壓力逐漸成為一種挑戰。熱點賬户短時間內餘額大量更新，或者熱門商品在營銷活動中限時搶購，都是這種場景的直接體現。熱點更新的本質是短時間內對數據庫中的同一行數據的某些字段值進行高併發的修改（餘額，庫存等），這其中的瓶頸主要在於關係型數據庫為了保持事務一致性，對數據行的更新都需要經過 “加鎖->更新->寫日誌提交->釋放鎖” 的過程，而這個過程實質上是串行的。因此，提高熱點行更新能力的關鍵在於如何儘可能縮短持有鎖的時間。為了緩解熱點行更新的問題，OceanBase提出了提前解行鎖（Early Lock Release)的優化方案，其原理見圖6。

圖6 提前解行鎖原理

1.優化前。

在用户發起 COMMIT 操作後，數據庫（DB）端會觸發日誌的持久化流程。這個過程包括以下4個步驟：

（1）將內存中的數據序列化並提交給本地的 Log buffer。

（2）數據庫將日誌數據發送到所有備機。

（3）等待多數備機同步日誌成功後，數據庫才認為日誌持久化成功。

（4）最終解鎖事務，並向客户端返回事務提交成功的應答。

在此流程中，一個事務的持鎖時間包含以下幾個部分：數據寫入、日誌序列化、同步備機的網絡通信、日誌刷盤的時間。對於三地五中心部署或者磁盤性能較差的情況，持鎖時間較長，容易對熱點行產生顯著的性能影響。

2.優化後。

在數據庫優化方案中，整體提交流程基本保持不變，但對解鎖時機進行了調整。在新的流程中，當日志序列化完成並提交給 Log buffer 後，立即觸發解鎖操作，而不再等待多數備機的日誌刷盤完成。這樣可以有效減少事務的持鎖時間。事務解鎖後，允許後續事務對同一行進行操作，實現了多個事務併發更新同一行的效果，從而提升了系統的吞吐量。

該優化生效的前提是OceanBase內核保證了以下關鍵特性：

• 提前解鎖的事務如果最終發生了回滾，後續凡是讀到該事務信息的事務都需要回滾，我們稱之為級聯回滾；
• 提前解鎖的事務尚未應答客户端之前，後續凡是讀到該事務信息的事務，都不能提前應答客户端；
• 只支持單機事務使用ELR優化，降低級聯回滾的概率。

3.優化效果。

基於上述優化方案，熱點行場景下的性能可以通過以下公式計算： 𝑇𝑃𝑆=1/{一個事務內熱點行的持鎖耗時}， 其中，持鎖耗時指的是從加鎖開始到事務提交完成的時間間隔。

在三地五中心的場景下，由於 SQL 的整體執行耗時為 30ms，事務的 COMMIT 響應時間（RT）約為 30ms。通過該優化，性能基本能夠與同城部署保持一致。

基於Sysbench單行更新，16c/64g阿里雲ECS環境做壓測，熱點行優化效果見表1。

表1 熱點行優化效果

（五）日誌聚合優化

數據庫系統中，WAL落盤是一個常見的動作。大量、高頻的小數據量日誌頻繁落盤，會產生大量的I/O，進而影響業務請求RT和系統的吞吐能力。為了解決或者優化該問題，數據庫領域常見的解決方案是聚合提交，簡言之，將多條日誌進行聚合，整體執行一次I/O。高併發寫入場景下，降低持久化日誌的IOPS和與該動作相關的CPU開銷，最終達到提升系統吞吐的效果。

OceanBase 4.x版本在3.x版本日誌聚合方案基礎上，重新做了設計，降低了單條日誌數據buffer拷貝的次數，以日誌流的維度，進一步提升了日誌聚合能力，架構如圖7所示。

圖7 OceanBase日誌引擎主、備副本邏輯管理結構

在圖7中，事務模塊提交日誌到GroupBuffer中做聚合，通過一定的聚合策略，將生成的日誌提交給ringbuffer實現的滑動窗口，即FixedSlidingWindow。該結構負責將聚合之後的日誌同步備機，觸發事務模塊日誌回調，推高本地最大連續committed lsn等信息。

為了滿足不同併發寫入場景下日誌的同步效率，OceanBase 4.x版本支持兩種日誌聚合策略：週期性和反饋式聚合。

• 週期性聚合：後台每隔1ms由一個獨立的線程觸發日誌聚合，該策略對高併發持續寫入比較友好。
• 反饋式聚合：對於低併發寫入場景，週期性聚合導致事務日誌存在1ms的延遲，業務影響較大。為了更好地解決該問題，OceanBase 4.x版本支持I/O線程的反饋式聚合策略，即日誌的刷盤線程完成當前I/O動作之後，主動觸發一次日誌聚合，進行下一次I/O動作。

上述兩種策略是互斥的，系統會根據當前的寫入流量自適應做選擇，兼顧了低併發下單個commit請求的延遲和高併發下系統整體的吞吐能力。基於32c * 3三副本環境，客户端單次模擬提交日誌大小512B，對比了OceanBase日誌模塊Palf、Etcd、Braft三款系統的持久化日誌的極限吞吐能力。經過驗證，相同併發下，OceanBase的日誌模塊Palf吞吐遠高於其他兩個系統（見圖8）。

圖8 OceanBase PALF、Etcd、Braft三款系統日誌持久化極限能力對比

（六）編譯優化

2024年OceanBase基於國產化和Intel芯片做了大量的性能優化，這些優化目前已經應用於實際的業務場景，並取得了顯著的性能提升。

PGO（Profile Guided Optimization)也被成為FDO（Feedback Directed Optimization）,是一類基於反饋式編譯優化的技術。其核心原理是基於生產環境中的實際流量採集profile數據，經過加工處理，獲取熱點函數、分支執行頻率結果信息，最後將將結果文件輸入編譯、鏈接器，重新編譯，產生優化之後二進制文件。該優化從多個方面提升了指令執行的效率（icache、itlb、page fault等）。

LTO（Link Time Optimization)，即鏈接時優化，是另一種編譯器優化技術。它允許編譯器在鏈接階段進行跨編譯單元的全局優化，可以完成全局視角的inline、virtual method優化，從而達到提升CPU icache命中率，進而提升系統的整體吞吐。

除了編譯優化之外，OceanBase通過彙編指令的優化，解決了ARM CPU下glibc原生load128原子操作性能瓶頸的問題；根據CPU架構的差異，自適應設置CACHE ALIGN的大小，從而實現了x86和ARM cpu下，熱點變量的自適應對齊能力，從而有效減少了false sharing的問題。 此優化顯著提升了OceanBase在國產芯片環境下的運行性能，為各行業信創推廣實施中降低了實施成本。

總結

本文圍繞高併發場景下的數據庫性能保障展開討論，指出在海量數據與高併發訪問的壓力下，高性能數據庫系統對業務支撐的重要性。並以OceanBase數據庫為例，從SQL引擎、事務引擎、存儲引擎、編譯優化等多個角度解讀了一款具備高性能的分佈式數據庫在高併發場景下的關鍵設計，基於上述設計與優化，OceanBase得以支撐不同業務場景中的高併發、高性能訴求。希望本文能夠為高併發系統的性能優化提供有價值的參考。

最後為大家推薦這個 OceanBase 開源負責人老紀的公眾號「老紀的技術嘮嗑局」，會持續更新和 #數據庫、#AI、#技術架構 相關的各種技術內容。歡迎感興趣的朋友們關注！

「老紀的技術嘮嗑局」不僅希望能持續給大家帶來有價值的技術分享，也希望能和大家一起為開源社區貢獻一份力量。如果你對 OceanBase 開源社區認可，點亮一顆小星星✨吧！你的每一個Star，都是我們努力的動力。