OceanBase 数据库架构图文档（源码视角）

1. 整体架构与定位

OceanBase 是分布式 Shared-Nothing 关系型数据库。每个节点对等运行单个 observer 进程 （入口 src/observer/main.cpp → ObServer::start()），节点内自带 SQL、存储、事务、分布式日志四大引擎， 基于 Multi-Paxos（在 PaLF 中实现）保证副本一致性与高可用（RPO=0，RTO<8s）。

关键特性（摘自 README.md / docs/docs/en/architecture.md）： 透明水平扩展 HTAP 单引擎 向量检索 MySQL 兼容 RPO=0 / RTO<8s 多租户隔离

1.1 集群拓扑

1.2 数据组织：Tenant → LS → Tablet → SSTable

2. 组件全景与源码布局

仓库根目录的关键模块（节选 src/）：

2.1 组件级关系图

3. OBServer 进程内分层架构

一个 OBServer 进程内的整体分层（参考 src/observer/ob_server.h、 ob_srv_network_frame、ob_srv_deliver、ob_srv_xlator、omt/）：

启动流程（ObServer::start() 简化）：

main() 
  ├─ ObServer::init()  // 解析 cfg、初始化 schema/location/log_block_mgr 等
  └─ ObServer::start()
     ├─ start ObSrvNetworkFrame  // 监听 2881/2882
     ├─ start OMT（多租户线程池）
     ├─ start ObLSService / ObTenantFreezer / ObCheckpointService
     ├─ start LogService (PaLF) + ApplyService + ReplayService
     ├─ register heartbeat to RootService
     └─ start RootService（若本机为 RS Leader 副本）

4. SQL 引擎流程

SQL 引擎入口 src/sql/ob_sql.h ObSql::stmt_query()。整条 pipeline：

4.1 Plan Cache 与软硬解析

语种路径 src/sql/plan_cache，ObPlanCache 用 SQL 文本（参数化后）+ schema_version + literval 模式为 key 缓存 ObPhysicalPlan。

• 硬解析：未命中 → 走完整 Parser→Rewrite→Optimize→CG；完成后渐热。
• 软解析：命中（且参数 / schema / stat 没变）→ 直接拿 plan，绑定新参数执行，省 90%+ 编译时间。
• 参数化：ob_plan_set.h 区分 FAST / PL"_TYPE / PS 模式；literal 类型维度去重。
• eviction：基于占用内存上限与命中率统计，使用 LRU + size 差额淘汰。

4.2 SPM：Manual vs Auto Baseline

SQL Plan Management（src/sql/spm）维护 evolved baseline。当优化器选择新计划且代价优于现有 baseline 阈值，会被加入 evolve 队列；DBA 或自动任务执行 verify 后确认升级为新 baseline。Outline（sql/ob_outline.h）和 UDR''udr` 提供人工 pin 计划能力。

4.3 优化器（基于代价的 CBO）

• 逻辑算子：ObLogicalOperator（sql/optimizer/ob_log_plan.h）树形 IR。
• Join Order 枚举：ob_join_order_enum_idp.cpp（IDP 动态规划）+ ob_join_order_enum_permutation.cpp。多表时折叠使用 System-R / IDP-2 with DPVol。
• 访问路径估算：ob_access_path_estimation.cpp，对每个候选索引基于 ObOptStatManager（直方图、NDV、Density）计算 cost。索引估算区分 ss_rowcount/emory/seek/selectivity 并考虑 covering、skip scan、回表 bitcost。
• 动态采样：ob_dynamic_sampling.cpp，统计信息不足时即席 OpenGauss 风采样（默认 level=2）。
• 分布式优化：考虑数据分布、Partition Pruning、并行度（DOP=ceil(目标ισα * CPU）、Exchange 算子插入位点。
• Col 剪裁与 Project Pushdown、Semi Join 转 Inner Join、Outer Job Elimination、Anti 重写、SubUnnest（ob_unnest）。

4.4 代码生成与向量化

• ObStaticEngineCG 遍历 CBO 计划树 → 构造 ObOpSpec（算子规格）+ 表达式 spec，全部序列化可缓存可 RPC 复用。
• 表达式分两类：expression-level ObExpr，exec 路径 ObExprCG 生成为函数指针 vec 求值；复杂表达式可被 src/objit（LLVM JIT）编译为原生机器码。
• Vec 执行：算子一次处理一个 ObBatchRows（默认 2048 行，由 ObExecContext::batch_size_ 控制）。HashJoin / HashAgg 走。ob_exec_hash_struct_vec.cpp。
• 执行内存：每个查询 ObSQLMemMgrProcessor 跟踪内存，超 workarea_percentage 走落盘（temp store）。

4.5 执行引擎算子家族

算子工厂在 sql/engine/ob_operator_factory.{h,cpp}。生成两种模式：

• 静态引擎（向量化）：上面所述。
• 火山式：ObOperator::get_next_row() 兼容路径（仅 PL 临时表或特定虚拟表内部走）。

4.6 谓词下推到存储与其他高级特性

• Index Filter Pushdown：storage/access/ob_sstable_index_filter 把可在 IndexBlock 上求值的谓词涂色，减少数据微块 IO。
• Pushdown Aggregate：storage/access/ob_pushdown_aggregate_vec 在 micro block 维度聚合，上层只需 reduce。
• PGG / Skip Scan：ob_index_skip_scanner + ob_skip_index_sortedness：对前缀列范围整块跳过，性能类似 MySQL Index Skip Scan。
• Adaptive Bypass：sql/engine/aggregate/ob_adaptive_bypass_ctrl：HashAgg 小基数直接 bypass 到 partial/单分区模式，避免哪些需要二次聚合的开销。
• SQL Trace / Optimizer Trace：ob_optimizer_trace_impl 把 plan 选择全过程埋点导出表 opt_trace 用于调优。

4.2 执行引擎

算子工厂在 sql/engine/ob_operator_factory.{h,cpp}。代码生成两种模式：

• 静态引擎（向量化）：ObStaticEngineCG 生成基于 ObBatchRows/ObBitVector 的批量化算子， 表达式可被 JIT 编译（src/objit 基于 LLVM）。
• 火山式：旧式 ObOperator::get_next_row() 兼容路径。

主要算子族：

5. DAS 与 PX 并行执行

5.1 DAS（Data Access Service）

DAS 是 SQL 与存储之间的数据访问中间层（src/sql/das），把每个 Scan/DML 拆分成对各 Tablet 的 ObDasTask， 并按数据位置远程/本地下推。核心类：ObDataAccessService、ObDASRef、ObDASScanOp、 ObDASInsert/Update/Delete/LockOp、定位 ObDASLocationRouter、重试 ObDASRetryCtrl。

5.2 PX（Parallel eXecution）

PX 实现 MPP 风格多机并行。源码在 src/sql/engine/px。关键概念：

• DFO（Data Flow Operator）：把计划切成多个 DFO，每个 DFO 是一段可独立并行的子计划（ob_dfo.h）。
• Granule：DFO 内的分片单位，调度到 SQC（Sub-Query Coordinator）上的工作线程（ob_granule_pump）。
• Exchange：DFO 间的数据重分布算子（Hash/Range/Pkey/Random/Broadcast），数据通过 sql/dtl（Data Transfer Layer）传输。
• PX Coord：根 DFO，负责调度（ob_dfo_scheduler）、Admission（ob_px_admission）。

6. 存储引擎：LSM-Tree + Tablet

OceanBase 的存储引擎是准 LSM-Tree 架构，对应代码 src/storage：

• 写入先进 MemTable（storage/memtable），同时通过 PaLF 写多副本 REDO。
• MemTable 冻结后 flush 成 Mini SSTable；多个 Mini 合并成 Minor SSTable； 每日（或基于阈值）所有副本一起做全局一致的 Major / Medium 合并。
• 所有 SSTable 都是不可变的 macro_block + micro_block 文件块（storage/blocksstable）。

6.1 写入路径

6.2 读取路径（合并多版本 + 多 SSTable）

位于 src/storage/access。读需要把同一行在 MemTable 与多层 SSTable 的版本「融合」：

6.3 微块格式与列式

• Macro Block：2MB 默认，blocksstable/ob_block_manager 管理。
• Micro Block：通常 16KB，是 IO 与压缩的最小单位。
• 编码：blocksstable/encoding 提供 RAW/Dict/RLE/Const/Diff/Prefix/HexString 等列式编码器， 并有 NEON/SIMD 优化解码（encoding/neon、ob_raw_decoder_simd.cpp、ob_dict_decoder_simd.cpp）。
• 列存（CS）：blocksstable/cs_encoding + storage/column_store 实现真正按列组织的 SSTable， 支持 HTAP 中的 AP 查询；CONVERT_CO_MAJOR_MERGE 把行存 major 转列存。

6.4 缓存层

6.5 MemTable 内部结构（常点）

数据源码：src/storage/memtable。每行结构：

ObMemtable
 ├─ ObQueryEngine         // 用 KeyBtree + HashIndex 索引
 │     ├─ ob_mvcc/ob_keybtree.{h,cpp}    // B+树，叶节点为 ObMvccRow*
 │     └─ ob_mt_hash.h                   // JIT hash 索引适配点查
 ├─ ObMvccEngine          // 行级 latch + write handler
 │     ├─ ObMvccRow      // 同 rowkey 多版本链表 ObMvccTransNode
 │     ├─ ObMvccTransNode // 一个版本：trans_version + data
 │     └─ row_latch.h    // 行写锁
 ├─ ObRedoLogGenerator     // 与 clog 衔接
 ├─ ObRowCompactor         // 行级 flush
 └─ ObMemtableCtx          // TX 局部上下文：回调链 + undo 链

写冲突处理

• 在 ObMvccRow 上持有 row_latch（ob_row_latch.h）写锁后追加新 TransNode。若发现已有 大于自身 trans_seq 的未提交版本，则触发 write-write 冲突，回滚自身（ob_row_conflict_handler.{h,cpp}）。
• 未提交数据不可见：读路径在 ObMvccEngine::get 中遍历版本链，只接受 trans_version <= snapshot_scn 或当前事务自己写的版本。

6.6 MVCC 可见性算法（必答）

读时刻保存 read_snapshot_scn（来自 ObTxReadCtx，可能取自 GTS / Standby Timestamp / Pure Local）。对每个版本 n：

if n.trans_version <= read_snapshot_scn AND
   n.commit_version 已经通过 PA + TxData落盘稳定:
    可见 n
elif n.write_seq < = own_tx_seq (是自己写的):  // self-modification
    在 curr_stmt 内可见
else:
    skip n

读会按 rowkey 融合：MemTable（活跃 / frozen） + 各层 SSTable（Mini / Minor / Major） → ObMultipleMerge 通过 LoserTree 多路归并，结合 bloom filter、index filter、push down filter 提前裁剪。

6.7 隔离级别实现

6.8 文件分布与 IO 路径

OB 不再像一维文件系统（一行一文件），而是在指定目录（squarerouter/ob_file_system_router.h）下按 tenant/ls/tablet 分层；macro block 由 ob_block_manager 以一组大小为 2MB 的 PGE 文件统一划块回收，写入通过 libeasy / io_uring 提交 IO。

7. 三级合并（Mini / Minor / Major / Medium）

合并类型在 src/storage/compaction/ob_compaction_util.h 定义：

enum MergeType {
  INVALID_MERGE_TYPE,
  MINOR_MERGE,            // 多个 Mini -> 更大 Mini
  HISTORY_MINOR_MERGE,
  META_MAJOR_MERGE,
  MINI_MERGE,             // MemTable flush -> Mini SSTable
  MAJOR_MERGE,            // 全量基线合并(每日)
  MEDIUM_MERGE,           // 中型增量合并
  ...
  CONVERT_CO_MAJOR_MERGE, // 行存 Major -> 列存 CG SSTables
  INC_MAJOR_MERGE,        // 增量 Major
};

7.1 合并层级与触发

7.2 合并的内部结构

• DAG 调度：compaction/ob_compaction_dag_ranker、ob_schedule_dag_func。
• 合并器：ob_partition_merger.*、ob_partition_merge_fuser.*（多 SSTable 行融合 fuser）。
• 过滤：i_compaction_filter 与 compaction/filter：丢弃已删除/过期版本，回收空间。
• 诊断：ob_compaction_diagnose、ob_compaction_suggestion。
• 列存合并： majors 转换为 CG（Column Group）sstable 详见 column_store。

7.3 合并类型逐项详解（源码：ob_compaction_util.h / ob_schedule_tablet_func / ob_basic_schedule_tablet_func）

7.4 MemTable 冻结的条件与流量控制

ObTenantFreezer（storage/tx_storage/ob_tenant_freezer.h）控制租户级写入门槛：

• 主动冻结：MemTable 写满到 freeze_trigger_percentage（默认 20%）后触发该 tablet 的小冻结。
• 写入限流：当所有 MemTable 占用达到 memstore_limit_percentage（默认 90%）开始让写操作回滚并走 Throttle（log_throttle、ob_memtable_write_throttle）。
• 主动 Major Freeze：每日 / 用户 ALTER SYSTEM MAJOR FREEZE / 介质变更 passed (compaction_suggestion)。
• Batch Freeze：将一批小 tablet 合并冻结，减少 clog entry、加速冻结。

7.5 调度优先级与 DAG Ranker

所有合并统一进入 DAG 调度器（share/scheduler/ + compaction/ob_compaction_dag_ranker）：每个 tablet 合并抽象为 dag（含多 task）。ObDagRanker 根据如下维度打分：

• 合并类型权重：MAJOR > CONVERT_CO_MAJOR > MEDIUM > MINOR > MINI > HISTORY_MINOR
• 等待时间 + tenant 优先级 + LS 优先级（受 suspend_merging 控制）
• 资源配额：每个 tenant 有限的 DAG slot，超过 push back
• 诊断反馈：ob_compaction_diagnose 检测 "schedule too slow"/"merge waiting" 等，ob_compaction_suggestion 给出自动放大资源/放宽时机的提议

7.6 合并过程内部细节（常问）

(a) Iterator、Fuser、Merger 三件套

• Iterator（ob_partition_merge_iter.h）：打开各参与 sstable，按 rowkey 顺序吐行。
• Fuser（ob_partition_merge_fuser.*）：把同行多个版本合并成「最终有效版」，处理 uncommitted row（来自 MemTable）和 multi-version 行。
• Merger（ob_partition_merger.*）：按行输出 macro block + micro block，通过 IndexBlockBuilder 构建索引。

(b) Compaction Filter（行级 GC）

• 接口：i_compaction_filter.h 的 ObICompactionFilter。
• 实现：compaction/filter/ + DDL filter staleness filter + TTL filter + MDS filter。
• 判定逻辑：当一行所有版本 max commit version < snapshot_version 且 无活跃事务回链 且 非稳态占位 → 丢弃。
• 影响：显著降低 Major 后的 SSTable 行数与体积。

(c) Progressive / 渐进式合并

ObProgressiveMergeHelper（ob_progressive_merge_helper.h）：当 Major 数据量巨大、一刀切会打垮 IO 时，按 macro block 「轮转合并」，由 progressive_merge_round 控制剩余未合并 range，逐 round 推进。INC_MAJOR_MERGE 类型即应用此机制。

(d) Medium List 与一致基线

7.7 失败与回滚

• DAG 状态：SCHEDULING / READY / RUNNING / FINISH / FAIL；失败 dag 复用同 dag_id 走 dag_status_manager 报告并指数退避重试（ob_schedule_status_cache）。
• 介质块写失败：丢弃 scaffolded macro block；连续失败 >= 阈值 -> tablet 异常报告 RootService。
• Reader 兼容：合并产出期间读路径仍可读老 Major + 其上增量直到新 SSTable meta 安装成功（atomicité via TabletPointer switch）。

8. 事务、MVCC 与 2PC 状态机

8.1 事务引擎总览

代码位置：src/storage/tx 与 src/storage/tx_storage。核心类：

• ObTransService（ob_trans_service.h）/ V4 ob_trans_service_v4：向 SQL 层提供 begin/commit/rollback。
• ObTxDesc：事务描述符（客户端视角事务）。
• ObPartTransCtx（ob_trans_part_ctx）：某 LS 上该事务的参与者上下文。
• ObTxCtxMgrV4：每个 LS 一个 ctx 管理器。
• ObITSManager / GTS / Standby Timestamp：分布式读时间戳 / 全局单调时间戳服务（ob_ts_mgr、ob_gts_*、ob_timestamp_service）。

8.2 MVCC

• MemTable 中每行挂在 ObMvccRow（memtable/mvcc/ob_mvcc_row），下行链表为本 row 的多个版本，每个版本带 trans_version（事务提交 SCN）。
• 读操作持 snapshot / SCN，决定可见版本；MemTable 索引用 KeyBTree（memtable/mvcc/ob_keybtree）。
• 写冲突检测：ob_row_conflict_handler + ob_row_latch（行级 latch）+ write-write 冲突回滚。
• ELR（Early Lock Release）：ob_tx_elr_handler。

8.3 两阶段提交（2PC）状态机

2PC 角色与状态见 src/storage/tx/ob_committer_define.h：

enum class Ob2PCRole  { UNKNOWN=0, ROOT, INTERNAL, LEAF };    // 树形分布式事务
enum class ObTxState   : uint8_t {
  UNKNOWN=0, INIT=10, REDO_COMPLETE=20, PREPARE=30,
  PRE_COMMIT=40, COMMIT=50, ABORT=60, CLEAR=70, MAX=100
};
enum class ObTwoPhaseCommitLogType  { OB_LOG_TX_INIT, OB_LOG_TX_COMMIT_INFO,
  OB_LOG_TX_PREPARE, OB_LOG_TX_PRE_COMMIT, OB_LOG_TX_COMMIT, OB_LOG_TX_ABORT, OB_LOG_TX_CLEAR };

2PC 协调器核心：ObTwoPhaseCommitter（storage/tx/ob_two_phase_committer.h），与上下游 commit 链 ob_two_phase_upstream_committer / ob_two_phase_downstream_committer 形成多级 commit tree， IDA 的「分布式事务」形态通过 ob_tx_2pc_ctx_impl、ob_tx_2pc_msg_handler 消息驱动。

8.4 REDO 提交优化 + Multi-Source

• REDO 日志与 MEMTable 入参同步通过 ob_redo_log_generator 流式提交，织入 PaLF（ob_tx_redo_submitter.h）。
• Multi-Source（ob_multi_data_source.*）：把 DDL/DUMP/Lob/外挂消息等跨模块信息以 commit 阶段离线写入 commit_info log（OB_LOG_TX_COMMIT_INFO），保证事务与外部副作用一致。
• Standby 节点回放：ob_tx_replay_executor 把提交信息回放到 follower 上，支持 StandbyReadable。

8.5 Commit Tree（树形分布式事务）

跨多个 LS 的分布式协调不是直接的 N-方 2PC，而是按依赖关系组织成 commit tree： Ob2PCRole 分 ROOT / INTERNAL / LEAF，由 root 服务（通常事主参与 LS）作为 coordinator； 每个分发到的 LS 都是一个 downstream committer；上游者应答前驱 agnostic。ObTwoPhaseCommitter 同时 向上游发送 PRE_COMMIT / COMMIT / ABORT，在 ob_two_phase_upstream_committer/ob_two_phase_downstream_committer 上完成树形级联。这样可以樹形隐藏 single-coordinator bottleneck，时延近似 O(log L)，避免某分片持有 participant 名称表。

8.6 TxFreeRoute（关键 OB 4.x 特性）

源码：ob_tx_free_route.*。允许同一逻辑事务在物理 多个 OBServer 节点之间路由（即便事务尚未提交， 客户端 SQL 也可被 ObProxy 路由到任意 server 执行 next part），而事务状态不再严格"绑在某一 server 上"。状态机 TxFreeRouteState：SAVEPOINT / COMMIT_INFO 等通过 commit_info log + 内存 session state snapshot 在 server 间传递。 这是 OLTP 负载均衡与秒级切关键。

8.7 Standby Read 与弱一致读

• Standby-Readable：standby（异地）租户可用快照在已回放 SCN 上提供读。
• 由 ob_tx_sby_read_ctx_helper / ob_standby_timestamp_service 维护可读 SCN。
• 弱一致读：read-only 允许"读到比当前最新稍旧数据"，换取路由灵活（ob_weak_read 路径）。

8.8 死锁检测

• 死锁检测：本地 deadlock_adapter（storage/tx/deadlock_adapter）等待样在行锁图谱上跑 DFS；检测到 cycle 则 abort 一个 victim。
• session wait chain + tx_describe 联动，超时（默认 100s）也会自动回滚。

8.9 XA / GTI 全局唯一 ID

• XA：ob_xa_*.{h,cpp} 支持 XA 协议（含 dblink）。
• GTI/独特 ID：ob_gti_source.h、ob_trans_id_service：租户级全局唯一 ID service，基于 clog 推进。
• GTS（Global Timestamp Service）：ob_gts_source 提供 monotone counter，作为快照 SCN 来源；多副本备份。

9. 日志服务 PaLF 与 Multi-Paxos

9.1 PaLF 是什么

PaLF = Paxos Log Facility（src/logservice/palf），是 OceanBase 自研的、面向 LS 的、基于 Multi-Paxos + Lease-based 选举的日志复制引擎。每个 LS 自己有一组 PaLF 实例。它不是 Fast Paxos （Fast Paxos 需要 2F+1 全部参与 prepare 阶段且不需 Leader），OceanBase 使用 Leader-based Multi-Paxos： 只有 Leader 接读写，其余副本只持久化和回放。Leader 通过独立的选举模块（palf/election） lease 选出。

9.2 PaLF 内部模块

9.3 角色与副本状态机（LogStateMgr）

角色 ObRole：LEADER / FOLLOWER；副本状态 ObReplicaState（log_define.h）：

enum ObReplicaState {
  INVALID_STATE = 0, INIT = 1, ACTIVE = 2, RECONFIRM = 3, PENDING = 4,
};

状态转移节选自 log_state_mgr.cpp：

9.4 Reconfirm 子状态机（新主上线修复不一致）

LogReconfirm::State（log_reconfirm.h）。这是 OceanBase Multi-Paxos 重要扩展——确保新 Leader 在服务写之前， 把多数派未确认的日志全部补齐，这是不同 Paxos 组从「无主 / 切主 / 宕机」直奔稳定阶段的恢复路径：

9.5 写日志路径

9.6 成员变更与降级

• 降级（degrade）：把失联副本置为「degraded paxos member」，不参与多数派计数；恢复后升级（upgrade）。
• 仲裁成员（arbitration member）：单节点参与多数派裁决但不存数据，跨可用区仲裁。log_config_mgr 支持。
• 列存在 ACTIVE / DEGRADED / LEARNER（学习者，只拉不投票）多种身份。

9.7 成员变更具体流程（reconfig）

源码：log_config_mgr.cpp 的 LogConfigChangeType 包括 ADD/REMOVE/CHANGE_NUM/DEGRADE/UPGRADE/ADD_ARB/REMOVE_ARB/CHANGE_LEADER/SETR_LOGONLY/...。一次变更分四步：

• Prepare 失败：直接弃 changelog，恢复旧配置。
• Commit 失败但 Prepare 已 ok：用「云 on disk」的 config_version 重试 reconfirm；不会留双 leader。
• 双 majority 计数：alive_paxos_replica_num_ 跟 expected_paxos_replica_num_，前者用于写多数派、后者用于配置多数派。

9.8 Reconfirm 内部细节

LogReconfirm（log_reconfirm.{h,cpp}）做新主补全多副本不一致日志。关键变量：

• max_lsn_：本机当前最大已 flush LSN。
• majority_max_log_server_：在多数派中具有最大 lsn 的 server。
• fetching_lsn_：正在从多数派拉取的目标 LSN。
• RECONFIRM_PREPARE_RETRY_INTERVAL_US=2s。

进程：选举胜选 → 本机 flush 完毕 → 向多数派发 prepare → 找出 lsn 最大者 → 拉 (max_lsn_local, majority_max_lsn] 区间日志 → 写 START_WORKING log（多 raft 唯一标志）→ 切 LEADER_ACTIVE。 START_WORKING commit 后才允许对该 LS append 新日志——这是 Multi-Paxos "断主重主不准漏日志" 的关键实现。

9.9 为什么 OB RTO < 8s？

1. Leader 离职 → 租约过期 < 3s：选举租约短（默认 9s 内可续；租约检查原 cycle 1s），断主到选主即 1~2s。
2. 选出后再做 Reconfirm：Reconfirm 只对不一致区间拉日志；正常情况下 majority_max_lsn == max_lsn 后 0 拉取即 START_WORKING。
3. START_WORKING log 是 single-log：仅一次 append + 多数派即 leader 可服务。
4. 磁盘 IO 复用 clog 多 Group batch：日志落盘单条很短，write 链路稳定 ms 级。
5. Replay 多 LS 并行回放（ob_replay_handler），follower 一直 hot，不需要冷启动。

实例：3F normal 切主一般在 1~3s 完成 START_WORKING；整 RTO 阈值 8s 留 buffer 给网络抖动 + brick 恢复。

9.10 Group Buffer 与 Sliding Window

OB 把多条 redo log entry 合成 LogGroupEntry（log_group_entry）批量落盘，减少 IO 次数。Sliding Window（log_sliding_window）维护 ack 位图：leader 维护每 follower 的 acked lsn；当"多数派 ack lon >= entry 的 lsn" 则该 entry committed 走 ApplyService。

10. 选举（Lease-based，非 Fast Paxos）

10.1 为什么独立一个选举模块

Multi-Paxos 本身只是协议，需要「谁来做 Leader」这一前提。OceanBase 把选举与共识拆开：选举模块 （src/logservice/palf/election）用 Lease 选举每 LS 独立维护一个稳定 Leader， Paxos 只在 Lease 失效或切主时被重新启动（见 LogStateMgr::switch_state）。

10.2 选举算法：基于 Prepare/Accept 两阶段 + Lease

关键代码：

• Proposer：palf/election/algorithm/election_proposer.（发起 Prepare/Accept）。
• Acceptor：election_acceptor（应答 Prepare/Accept、记录 promised_proposal_id）。
• 消息：palf/election/message/election_message：Prepare/Accept 请求与应答，带优先级（election_priority）。
• 优先级：按 (data_seq, member_version) 比较，多数情况下让日志最全者当选，避免反复选举。
• 协议降级：temporarily_downgrade_protocol_priority：短暂降低本副本优先级（如刚恢复但日志较少）。

10.3 Lease 与领导者连任

Leader 持有严格租约，租约期内不开新一轮选举；租约即将到期时由 Leader 自我续约（lease renew）， 减少选举震荡。租约过期后由 Follower 触发新一轮。RCHandle、RequestChecker 处理过期与消息时序。

10.4 选举优先级与避免脑裂 / 反复选举

ElectionPriority（palf/election/interface/election_priority.h）的比较维度（从高到低）：

1. 本地 log_lsn / proposal_id（日志更全者优先）
2. 成员变更版本（更晚变更优先，避免老 member 抢占）
3. server_id（兜底确定性）

因此在切主时原则上由日志最全者当选，避免后续 leader 还要回拉 follower 日志的代价。temporarily_downgrade_protocol_priority 提供外部介入：刚恢复的 server 短时下调自己优先级，避免它当选后立刻被更全者"切回来"。

10.5 切主（ChangeLeader）路径

11. 索引体系（B+ / LSM / 全文 / 向量）

11.1 索引类型矩阵

索引定义见 src/share/schema/ob_schema_struct.h（ObIndexType）。OceanBase 的二级索引并不直接坐落 B+Tree 数据结构上，而是「索引表」——每张索引表本身就是一个 Tablet，存储布局与数据表一致（LSM-Tree）。 用户表与索引表之间通过 rowkey 维持对应关系。

11.2 索引存储：Index Block 树

每张 SSTable 由 Index Block 树（多级 + 微块）组织，源码在 src/storage/blocksstable/index_block：

索引扫描核心组件（src/storage/access）：

• ob_index_block_tree_traverser：B+ 树遍历。
• ob_index_tree_prefetcher：预取优化。
• ob_index_skip_scanner + ob_skip_index_sortedness：Skip Scan（跳过不匹配段）。
• ob_sstable_index_filter：下推到 SSTable 的索引层过滤（列裁剪 + 谓词）。

11.3 向量索引

位于 src/sql/das/ob_das_vec_define、ob_vector_index_lookup_op、ob_das_search_index_utils、 src/sql/optimizer/ob_access_path_estimation。IVF 系列： Centroid Local（质心）+ CID-Vector Local（每个质心所属向量）+ Rowkey-CID Local（反向映射），3 张辅助 Tablet 联合检索； HNSW：单独的图结构辅助表。SQL 层支持 VECTOR 数据类型、距离函数（L2/IP/Cosine）与混合检索 （sql/code_generator/ob_hybrid_search_cg_service_*）。

11.4 全文索引 FTS

位于 src/storage/fts、sql/code_generator/ob_hybrid_search_cg_service_fulltext。结构：分词后的 doc-word 倒排辅助表（is_fts_doc_word_aux），查 MATCH AGAINST 时复用 parser 分词结果做倒排合并。支持 local/global/global-local 三种形态。

11.5 多值索引

用于 JSON / ARRAY 列：把数组每个元素展开到一张倒排辅助表，使 MEMBER OF、JSON_CONTAINS 等可以走索引。

11.6 索引选择与代价（常问）

• Covering Index：ObAccessPathEstimation 计算时判断 select/where 列是否全部在索引前缀 + 主键中；是则可避免回表 lookup cost。
• Index Skip Scan（ob_index_skip_scanner、ob_skip_index_sortedness）：当前缀列基数小但取值离散时，对每个前缀值都做 1 次 range scan，等效消除前缀谓词。代价模型上要算多次 micro block 开销，CBO 决定是否启用。
• Index Condition Pushdown / Index Filter（ob_sstable_index_filter）：能在索引块上解出的谓词 → 直接过滤；其余谓词 push 到 row-level（push down filter）。
• Forward / Backward Scan：index_block 的微块迭代器支持双向扫描，配合 ORDER BY DESC/ASC 避免 sort。
• 索引统计采样估算：列 ESTimation 依赖 ObOptStatManager 的直方图，索引列同样采直方图 + density；global/local 索引采用 global stats.

11.7 复合表 / Clustered Index / RowStore-vs-ColumnStore

• Clustered Index Block（ob_clustered_index_block_writer）：与数据 macro block 同构存储，将某索引列集和数据内容物理交错，减少回表。
• Column Store (CG SSTable)：列存基于 Column Group，把大量列分组到不同 SSTable，读时按需打开部分 CG：OLAP 场景 IO 显著降低。

11.8 向量检索执行链路（IVF + HNSW）

12. RootService 与多租户

12.1 RootService 职责

RootService（src/rootserver）是一个集群级单点服务（实际上也是根 LS 的 Leader 副本承担），负责：

• 集群管理：bootstrap（ob_bootstrap）、server 上下线、心跳（ob_heartbeat_service）、ob_all_server_checker。
• Schema / DDL：ob_ddl_service、ob_ddl_operator、ob_index_builder、ob_lob_meta_builder、catalog（ob_catalog_ddl_*）、AI model（ob_ai_model_ddl_*）。
• 负载均衡：balance/、ob_root_balancer、ob_partition_balance、ob_balance_ls_primary_zone：Unit 与 LS 在 zone 间迁移。
• 容灾：ob_disaster_recovery_*、教师副本切换、补副本（ob_lost_replica_checker、ob_empty_server_checker）。
• 冻结 / 合并：freeze/ob_root_minor_freeze、compaction_ttl/：调度 Major / Medium。
• 备份恢复：backup/。
• 物化视图：mview/ 与 ob_mlog_builder。
• DDL 任务框架：ddl_task/、direct_load/。

12.2 多租户与资源隔离

• Unit（资源单元）：定义 CPU/MEM/磁盘 上限；一个 Unit 在某一 OBServer 上只为一个 Tenant 服务。
• Pool（资源池）：多个跨 zone 的 Unit 组合；租户绑定 Pool。
• 租户模式：sys（系统租户）、Meta（每用户租户一一对应的元数据租户）、User（MySQL / Oracle 模式）。
• 每个租户的 LS 不在物理上跨集群同步（除了主备 standby 物理 sync 备份），但跨 zone 副本通过 PaLF 同步。

13. 关键源码索引（导航）