物化视图刷新跑完了，效果怎么样？刷新前基表变了多少行、刷新花了多久、每条内部 SQL 执行了几次——这些问题的答案都藏在 OceanBase 的刷新统计表里。本文要读的 ob_mview_refresh_stats_collect.cpp（约 480 行）就是统计的”采集层”，它与此前解读过的清理执行器（ob_mview_refresh_stats_purge）一收一放，构成 4.3 物化视图统计体系的闭环。文件核心是两个类：ObMViewRefreshStatsCollection 负责单个物化视图的统计采集，ObMViewRefreshStatsCollector 负责整次 REFRESH 调用（可能一次刷多个 MV）的运行级汇总，最终把数据落到 __all_mview_refresh_stats、__all_mview_refresh_change_stats、__all_mview_refresh_stmt_stats、__all_mview_refresh_run_stats 四张内部表。
分类： OceanBase
OceanBase源码解读：物化视图维护任务 ob_mview_maintenance_task
OceanBase 4.3 引入物化视图（Materialized View）后，系统里多了一类需要长期”养护”的对象：用户的 MV 可能被反复创建删除，而它的元数据记录、刷新统计、自动刷新作业分散在多张系统表里。如果某个 MV 被删除后残留了元数据（孤儿 MV），这些脏记录会越积越多。本文解读的 ob_mview_maintenance_task.cpp（位于 rootserver/mview 目录，共 370 行）就是负责这件事的后台任务——ObMViewMaintenanceTask。它是物化视图体系里的”守门员”：每分钟巡检一轮，分批扫描全租户物化视图，找出表结构已删但元数据还在的孤儿 MV，把刷新统计、DBMS Scheduler 刷新作业和元数据记录一并清掉。整个任务采用”定时器 + 状态机”的写法，每 10 秒醒一次、每次只做一小步，天然支持断点续传，是读懂 OceanBase 后台任务设计风格的绝佳样本。
OceanBase源码解读：物化视图日志修剪任务 ob_mview_trim_mlog_task
物化视图日志（MLog）是 OceanBase 4.3 MV 快速刷新体系的基石：基表每次 DML 都会往 MLog 里追加一条变更记录，供 MV 做增量刷新。但 MLog 的结构不是一成不变的——随着 MV 增删、列被修改、刷新方式演进，MLog 里会逐渐积累”没人引用”的冗余列，甚至整个 MLog 都可能变成无主之物。本篇解读的 ob_mview_trim_mlog_task.cpp（483 行）就是解决这个问题的后台任务：ObMViewTrimMLogTask，一个跑在 RootService 里、周期性执行的”MLog 瘦身师”。它对每个 MLog 做一次审计：没有 MV 还需要就整体删除；仍有 MV 依赖但存在冗余列，就按引用列集合重建一个更瘦的新 MLog 替换旧的，从源头降低 DML 的日志写放大。
OceanBase源码解读：物化视图刷新统计清理执行器 ob_mview_refresh_stats_purge
物化视图的刷新统计是一份「会自己长大」的数据：每一次刷新、每一次重试、每一条刷新语句都会往内部表里写记录。如果不做清理，这些诊断类数据会无限膨胀，最终拖慢整个租户的元数据访问。OceanBase 4.3 把清理逻辑收敛到一个只有 88 行的工具文件 storage/mview/ob_mview_refresh_stats_purge.cpp 里，类名 ObMViewRefreshStatsPurgeUtil，全静态方法，只有一个入口 purge_refresh_stats。代码虽短，但它同时要处理三件事：三张明细表的级联删除、聚合行的引用计数维护、以及为上层定时任务提供准确的「清理配额」语义。本文按「四表模型 → 核心数据结构 → 五阶段流程 → 两个设计细节」的顺序拆开看。
继续阅读OceanBase源码解读：物化视图刷新统计清理执行器 ob_mview_refresh_stats_purge
OceanBase源码解读：物化视图日志清理器 ob_mlog_purge
物化视图的快速刷新（FAST REFRESH）依赖一张”变更日志表”——MLog（materialized view log）。基表每发生一次 DML，MLog 就追加一行带旧值/新值的变更记录。只写不删，这张表迟早会吃掉整个租户的存储空间，所以必须有人负责回收。OceanBase 4.3 里承担这个职责的是 storage/mview/ob_mlog_purge.cpp 中的 ObMLogPurger。这篇文章拆解它的三段式流程，以及最核心的那个问题：一次到底能删到哪个位点。
OceanBase源码解读：物化视图刷新统计清理任务
物化视图（Materialized View）每次刷新都会在系统表 __all_mview_refresh_stats 里记录一条刷新统计：刷新耗时、刷新 SCN、成功与否等。这些统计是运维观测的重要依据，但如果只写不删，长期运行下来这张表会无限膨胀。OceanBase 4.3 为此引入了一个专门的后台任务——ObMViewRefreshStatsMaintenanceTask，它按用户为每个物化视图设置的保留期（retention_period），周期性地清理过期的刷新统计记录。本文解读它的实现文件 rootserver/mview/ob_mview_refresh_stats_maintenance_task.cpp，重点看两个设计亮点：一是”单拍自续”的定时器调度模式，二是游标驱动的分批限流清理。
OceanBase源码解读：物化视图快照推进任务 ob_mview_push_snapshot_task
在 OceanBase 4.3 的物化视图（MV）体系里，”大版本刷新”（major refresh mv）是一种重量级操作：它不是在事务里实时计算刷新，而是依赖存储层的多版本快照，把刷新推迟到一次 Major Compaction 中批量完成。这就带来一个关键问题——刷新期间所依赖的最低快照版本（min_refresh_scn）必须被系统”保住”，否则事务的多版本数据一旦被回收，刷新就会读到不完整的数据。本文要解读的 ob_mview_push_snapshot_task.cpp（209 行）正是解决这个问题的组件：一个由 RootService 定时驱动的”快照推进任务” ObMViewPushSnapshotTask，它周期性地把所有大版本刷新物化视图所需的最小快照 SCN 推送到快照表，为刷新链路兜底。
OceanBase源码解读：物化视图刷新信息缓存任务 ob_mview_update_cache_task
在 OceanBase 4.3 的物化视图（Materialized View）体系里，有一类 MV 的刷新节奏被绑定在基表的合并/冻结节拍上，也就是 REFRESH_MODE = MAJOR_COMPACTION。合并线程推进 major freeze 时，必须反复回答一个问题：这些 MV 里的数据是否已经刷到当前版本？这个判定处在极热路径上，如果每次都去扫一遍元数据表 __all_mview，代价完全不可接受。于是就有了本文要解读的 ob_mview_update_cache_task.cpp——一个专职”抄表”的后台任务：它每 5 秒把 __all_mview 里每个 MV 的 LAST_REFRESH_SCN 抄进内存哈希表，让热路径只查内存。整个文件不到 200 行，却是理解 OceanBase「持久化元数据 + 内存旁路缓存」这套读写分离设计的好样本。
OceanBase源码解读：MV依赖更新任务 ob_mview_update_deps_task
物化视图支持嵌套构建——一个 MV 可以基于另一个 MV 建立，这样就形成了一张”依赖图”。当依赖链上的基表或其他 MV 发生 DDL 变更后，这张依赖图可能过期，如果不及时重建，刷新调度就会拿到错误的依赖关系。本文解读的 ob_mview_update_deps_task.cpp（全文 136 行）就是负责这件事的后台定时任务：ObMViewUpdateDepsTask。它跑在 RootService（RS）侧，周期性探测当前租户是否存在嵌套 MV 依赖，一旦发现就触发整张依赖图的全量重建。代码虽短，却是物化视图元数据一致性的重要守护者。
OceanBase源码解读：物化视图 MDS 操作记录同步任务
在 OceanBase 4.x 的物化视图（Materialized View）体系里，有一个不起眼但很关键的定时任务：ObMViewMdsOpTask。它的职责是周期性扫描系统日志流（SYS_LS）上的事务上下文，把仍活跃事务携带的 mview 相关 MDS（Multi-Data Source，表级事务性元数据管理框架）操作收集到内存 Map 中，同时清理那些对应事务已经消失、且记录本身已过期的条目。简单说，它是”刷新任务读取 mds 记录”与”事务真实状态”之间的同步桥梁——没有它，刷新任务可能拿到早已回滚事务的脏数据，内存 Map 也会随时间无限膨胀。