物化视图（Materialized View）是 OceanBase 4.3 的旗舰特性之一：把一条查询 SQL 的结果实体化存储成一张真实表，查询时直接读表，免去每次实时聚合计算。但实体化带来一个经典问题——基表数据一直在变，物化视图里的”快照”怎么跟上？答案就是本篇的主角 ob_mview_refresh.cpp（约 1000 行）：物化视图的刷新执行器 ObMViewRefresher，负责把 MV 的数据从上次刷新点安全地推进到当前时点。它提供两条刷新路径：FAST 增量刷新（消费基表 MLog 变更日志，只算差量）和 COMPLETE 全量刷新（把定义 SQL 重新算一遍），并提供自适应选路逻辑在两者间智能切换。
OceanBase源码解读：RootService总控入口 ob_root_service.cpp
如果把 OceanBase 集群比作一艘船，RootService（RS）就是驾驶舱，而 rootserver/ob_root_service.cpp 里的 ObRootService 类则是驾驶舱里的总控台。它运行在 RS Leader 节点，负责集群成员管理、租户与资源池调度、DDL 路由、心跳租约、升级、系统包加载等全局事务。与 observer 内其它子系统按租户实例化不同，RS 相关逻辑是集群级别的单例，必须在正确的时间以正确的顺序把 Server 管理、Zone 管理、Unit 管理、DDL 服务、均衡器、检查器等一系列模块装配起来。本文聚焦这个总控入口，看 OceanBase 如何用一套状态机驱动整个集群的启停与运维。
OceanBase源码解读：事务服务总控入口 ob_trans_service.cpp
在 OceanBase 的存储引擎中，事务模块负责保证 ACID、多版本并发控制（MVCC）以及分布式两阶段提交（2PC）。ob_trans_service.cpp 位于 storage/tx 层，是事务引擎在 observer 进程内的租户级门面与总控。它通过 MTL（Multi-Tenant Layer）机制为每个租户独立实例，对上承接 SQL 层的事务请求，对下统管事务上下文管理器、事务描述符管理器、GTS 源、RPC、定时器以及重复表（dup table）等子系统。本文聚焦这个“总控入口”，看它如何把散落的子系统装配成一套可运行、可停机、可扩展的事务服务。
OceanBase源码解读：Palf选主入口 election_impl.cpp
在 OceanBase 的日志流（Palf）体系中，每个日志流（LS）都由一套 Paxos 风格的选举协议选出唯一 Leader，本文解读这套协议的总控实现 election_impl.cpp。它位于 logservice/palf/election/algorithm/ 目录下，与同目录的 election_proposer.cpp（提议者）、election_acceptor.cpp（接受者）共同构成选主协议的算法层。ElectionImpl 自身不实现投票细节，而是扮演”门面 + 调度器”角色：对外提供初始化、成员变更、切主等接口，对内持有 proposer 与 acceptor 两个核心角色，并把五种选举消息统一分发下去。
OceanBase源码解读：Palf日志句柄 palf_handle_impl.cpp
PalfHandleImpl 是 OceanBase PALF（Paxos Asynchronous Log Flush）日志服务的核心句柄，一个实例对应一个日志流（palf_id）。它向上承接 SQL/事务层的日志提交请求，向下协调状态机、成员配置、选举、日志引擎与滑动窗口，完成日志的写入、复制、落盘与提交。可以把 PalfHandleImpl 理解为”单日志流控制器”：所有与该日志流相关的 Paxos 协议行为，最终都汇聚到这个类中。
OceanBase源码解读：Palf日志引擎 log_engine.cpp
OceanBase 的 Paxos 一致性协议由两层构成：上层是 PalfHandleImpl 负责副本间协议协调（选举、日志序号分配、确认），下层则是 LogEngine 负责把已经达成共识的日志条目落盘、读取、推送给 follower。LogEngine 是 PalfHandleImpl 与物理块存储之间的”单机适配层”，本文聚焦其核心实现 log_engine.cpp（1915 行），梳理它的架构位置、关键数据结构、初始化与重启路径、以及面向协议层的高频入口。
OceanBase源码解读：SSTable持久化存储引擎 ob_sstable.cpp
SSTable（Sorted-String Table）是 OceanBase 存储引擎的持久化基座。当 MemTable 中的数据积累到一定量或触发合并条件时，内存数据会被刷盘为 SSTable。每个 Tablet 持有多个 SSTable，按版本从新到旧排列，读取时由 TableStore 统一调度。本文深入解析 ob_sstable.cpp 的核心实现，涵盖创建初始化、读写访问、序列化/反序列化及宏块引用计数四大关键路径。
OceanBase源码解读：存储引擎Tablet单元 ob_tablet.cpp
Tablet 是 OceanBase 存储引擎的核心管理单元，位于 Log Stream（LS）之下、SSTable 与 Memtable 之上。一个 Tablet 对应一张表某个分区的全部数据，管理该分区的存储元数据、SSTable 列表、Memtable 句柄以及宏块引用计数。ob_tablet.cpp 共 9278 行，是整个 storage/tablet 目录下体量最大的文件，涵盖了 Tablet 从创建、迁移、合并、序列化到引用计数管理的完整生命周期。本文聚焦其中 8 个核心函数，揭示 Tablet 的架构设计精髓。
OceanBase源码解读：SQL代码生成器入口 ob_code_generator.cpp
OceanBase源码解读：SQL代码生成器入口 ob_code_generator.cpp
SQL 经过解析、语义分析、改写和优化后，得到逻辑执行计划。代码生成阶段把它翻译成物理执行计划。ob_code_generator.cpp 是编排入口，ob_static_engine_cg.cpp 负责把逻辑算子递归转换为物理算子规约（ObOpSpec）。
OceanBase源码解读：存储引擎内存表 ObMemtable
OceanBase 的存储引擎采用 LSM-Tree 架构，所有写入首先进入内存表（Memtable），再按一定策略冻结并转储为 SSTable。ObMemtable 是单个 Tablet 的内存表实体，向上承接 SQL 执行层与事务层的 set/get/scan/lock/replay 请求，向下通过 MVCC 引擎、Query 引擎和 Memstore 分配器完成并发控制、索引维护与内存管理。本文选取其初始化、读写路径与冻结/刷盘流程做重点解读。