• 一、创建基表、MLOG 与增量刷新物化视图
  • 1.1 创建基表
  • 1.2 创建物化视图日志（MLOG）
  • 1.3 创建增量刷新物化视图（每分钟自动刷新）
• 二、物化视图运行状态验证（6 个诊断维度）
  • 2.1 确认物化视图基本信息（dba_mviews）
  • 2.2 查看刷新运行统计（dba_mvref_run_stats）
  • 2.3 确认依赖关系（dba_mview_deps）
  • 2.4 查看正在刷新的物化视图（dba_mview_running_jobs）
  • 2.5 确认调度 JOB 信息（dba_scheduler_jobs）
• 三、手动刷新并行度控制实验（3 种方法对比）
  • 方法 1：设置系统变量 mview_refresh_dop
  • 方法 2：DBMS_MVIEW.REFRESH 显式指定 refresh_parallel
  • 方法 3：设置 MV 的 PARALLEL 属性（部分生效）
• 四、刷新数据量变化观测
  • 4.1 数据灌入
  • 4.2 查看刷新数据变化量（dba_mvref_change_stats）
  • 4.3 两表关联查询（run_stats + change_stats）
• 五、基表 DDL 变更限制与处理
  • 5.1 直接修改报错
  • 5.2 正确的处理流程（6 步）
• 六、enable_mlog_auto_maintenance 参数实验
  • 6.1 参数说明
  • 6.2 开启后的效果
• 七、实时物化视图创建与对比
  • 7.1 创建实时物化视图
  • 7.2 对比普通 MV 与实时 MV
• 八、MLOG 清理机制观测
  • 8.1 实验过程
  • 8.2 延迟清理
  • 8.3 刷新统计中的变化量验证
• 九、observer.log 日志观测（全量刷新）
  • 9.1 获取 trace_id
  • 9.2 observer.log 中的刷新日志
  • 9.3 刷新统计验证（dba_mvref_stats）
• 十、核心知识点总结

一、创建基表、MLOG 与增量刷新物化视图

1.1 创建基表

创建两张业务表 orders（订单表）和 items（商品维度表），构成经典的订单-商品关联模型：

-- 订单表（50000+ 行）
CREATE TABLE orders (
    order_id   BIGINT PRIMARY KEY,
    item_id    BIGINT NOT NULL,
    price      DECIMAL(10,2),
    amount     DECIMAL(12,2),
    order_date DATE,
    region     VARCHAR(50)
);

-- 商品维度表（3 行）
CREATE TABLE items (
    item_id    BIGINT PRIMARY KEY,
    item_name  VARCHAR(200),
    category   VARCHAR(100),
    price      DECIMAL(10,2)
);

1.2 创建物化视图日志（MLOG）

为两张基表分别创建 MLOG，关键参数：

• WITH PRIMARY KEY, ROWID, SEQUENCE (...) — 记录主键、行ID、序列号及指定列的变更
• INCLUDING NEW VALUES — 支持增量刷新时记录新值

CREATE MATERIALIZED VIEW LOG ON orders
WITH PRIMARY KEY, ROWID, SEQUENCE (item_id, amount, order_date, region)
INCLUDING NEW VALUES;

CREATE MATERIALIZED VIEW LOG ON items
WITH PRIMARY KEY, ROWID, SEQUENCE (item_name, category, price)
INCLUDING NEW VALUES;

1.3 创建增量刷新物化视图（每分钟自动刷新）

CREATE MATERIALIZED VIEW mv_orders_items
    REFRESH FAST ON DEMAND
    START WITH NOW() NEXT NOW() + INTERVAL 1 MINUTE
    AS
    SELECT
        o.order_id, o.item_id, o.order_date, o.region,
        i.item_name, i.category, i.price, o.amount,
        COUNT(*) AS cnt
    FROM orders o
    JOIN items i ON o.item_id = i.item_id
    GROUP BY o.order_id, o.item_id, o.order_date, o.region,
             i.item_name, i.category, i.price, o.amount;

关键语法解读：

• REFRESH FAST — 增量刷新（仅应用 MLOG 中的变更）
• ON DEMAND — 按需刷新（由调度 JOB 触发，非自动提交时刷新）
• START WITH NOW() NEXT NOW() + INTERVAL 1 MINUTE — 立即开始，每分钟调度一次
• 包含 JOIN + GROUP BY + COUNT(*)，满足 FAST 刷新条件

二、物化视图运行状态验证（6 个诊断维度）

2.1 确认物化视图基本信息（dba_mviews）

SELECT mview_name, owner, rewrite_enabled, refresh_mode, refresh_method,
       last_refresh_type, last_refresh_date, staleness
FROM   oceanbase.dba_mviews
WHERE  mview_name = 'MV_ORDERS_ITEMS';

输出结果：

2.2 查看刷新运行统计（dba_mvref_run_stats）

SELECT run_owner, mviews, refresh_id, method, num_mvs,
       start_time, end_time, elapsed_time, parallelism,
       number_of_failures, complete_stats_available
FROM   oceanbase.dba_mvref_run_stats
WHERE  mviews LIKE '%MV_ORDERS_ITEMS%'
ORDER  BY start_time DESC;

输出结果（6 次连续自动刷新记录）：

关键发现：

• 每分钟自动刷新一次，method 为 NULL（自动调度不标记 method）
• parallelism = 4（默认并行度）
• elapsed_time = 0（空表数据量小，刷新耗时不到 1 秒）
• number_of_failures = 0，complete_stats_available = Y，全部成功

2.3 确认依赖关系（dba_mview_deps）

SELECT mview_owner, mview_name, dep_owner, dep_name, dep_type
FROM   oceanbase.dba_mview_deps
WHERE  mview_name = 'mv_orders_items';

2.4 查看正在刷新的物化视图（dba_mview_running_jobs）

SELECT svr_ip, svr_port, table_name, job_type, session_id,
       parallel, job_start_time, read_snapshot
FROM   oceanbase.dba_mview_running_jobs
WHERE  table_name = 'mv_orders_items';
-- Empty set（当前无正在运行的刷新任务）

2.5 确认调度 JOB 信息（dba_scheduler_jobs）

SELECT owner, job_name, job_type, job_action,
       repeat_interval, next_run_date, last_start_date,
       state, enabled
FROM   oceanbase.dba_scheduler_jobs
WHERE  job_action LIKE '%mv_orders_items%';

关键发现：

• JOB 名由系统自动生成，格式 MVIEW_REFRESH$J_
• nested=>FALSE 表示不级联刷新依赖的物化视图
• 调度间隔与创建时指定的 INTERVAL 1 MINUTE 一致

三、手动刷新并行度控制实验（3 种方法对比）

方法 1：设置系统变量 mview_refresh_dop

-- 查看默认值
SHOW VARIABLES LIKE "mview_refresh_dop";
-- 默认值 = 4

-- 设置当前会话并行度
SET mview_refresh_dop = 16;

-- 手动刷新
CALL dbms_mview.refresh('mv_orders_items', 'f');  -- 增量
CALL dbms_mview.refresh('mv_orders_items', 'c');  -- 全量

验证结果（从 dba_mvref_run_stats 提取）：

结论： mview_refresh_dop 仅对手动调用 DBMS_MVIEW.REFRESH 生效，不影响自动调度任务。

方法 2：DBMS_MVIEW.REFRESH 显式指定 refresh_parallel

CALL dbms_mview.refresh('mv_orders_items', 'f', refresh_parallel => 16);
CALL dbms_mview.refresh('mv_orders_items', 'c', refresh_parallel => 16);

验证结果：

结论： 显式指定参数优先级最高，效果与方法 1 一致。

方法 3：设置 MV 的 PARALLEL 属性（部分生效）

ALTER MATERIALIZED VIEW mv_orders_items PARALLEL 16;
CALL dbms_mview.refresh('mv_orders_items', 'f');
CALL dbms_mview.refresh('mv_orders_items', 'c');

验证结果（关键对比数据）：

重要结论：

• ALTER MATERIALIZED VIEW ... PARALLEL N 设置的并行度只对自动调度任务生效
• 手动调用 DBMS_MVIEW.REFRESH 不受 MV PARALLEL 属性影响，仍使用 mview_refresh_dop 默认值

并行度优先级总结：

四、刷新数据量变化观测

4.1 数据灌入

-- 维度表：3 行
INSERT INTO items VALUES (1, '笔记本电脑', '电子产品', 5999.00);
INSERT INTO items VALUES (2, '办公桌', '家具', 1500.00);
INSERT INTO items VALUES (3, '咖啡机', '家电', 899.00);
COMMIT;

-- 订单表：50000 行（利用 information_schema.tables 笛卡尔积生成序列号）
INSERT INTO orders
SELECT seq, MOD(seq, 3) + 1, ROUND(RAND() * 5000, 2),
       DATE_ADD('2026-06-01', INTERVAL MOD(seq, 30) DAY),
       CASE MOD(seq, 3) WHEN 0 THEN 'SH' WHEN 1 THEN 'BJ' ELSE 'GZ' END
FROM (
    SELECT @rownum := @rownum + 1 AS seq
    FROM information_schema.tables a, information_schema.tables b,
    (SELECT @rownum := 0) r
    LIMIT 50000
) t;

4.2 查看刷新数据变化量（dba_mvref_change_stats）

SELECT refresh_id, mv_name, tbl_owner, tbl_name,
       num_rows_ins, num_rows_upd, num_rows_del, num_rows
FROM   oceanbase.dba_mvref_change_stats
WHERE  mv_name = 'mv_orders_items'
ORDER  BY refresh_id DESC LIMIT 30;

关键输出（数据灌入后的刷新记录）：

关键发现：

• refresh_id = 792325 这次刷新捕获到了变更：orders 插入 50000 行，items 插入 3 行
• 前后相邻的刷新记录 num_rows_ins = 0，说明没有数据变更时增量刷新无实际操作

4.3 两表关联查询（run_stats + change_stats）

SELECT r.refresh_id, r.run_owner, r.mviews, r.method,
       r.start_time, r.end_time, r.elapsed_time, r.parallelism,
       c.tbl_name, c.num_rows_ins, c.num_rows_upd,
       c.num_rows_del, c.num_rows
FROM   oceanbase.dba_mvref_run_stats r
LEFT   JOIN oceanbase.dba_mvref_change_stats c
       ON r.refresh_id = c.refresh_id
WHERE  r.mviews LIKE '%MV_ORDERS_ITEMS%'
ORDER  BY r.start_time DESC LIMIT 30;

此查询将刷新运行统计与基表数据变化量关联，可一次性看到：某次刷新的耗时、并行度、以及各基表的 INSERT/UPDATE/DELETE 行数。

五、基表 DDL 变更限制与处理

5.1 直接修改报错

ALTER TABLE orders MODIFY amount DECIMAL(12,2);
-- ERROR 1235 (0A000): modify column to table with materialized view log is not supported

原因： 基表存在 MLOG，OceanBase 不允许直接修改有 MLOG 依赖的表的列定义。

5.2 正确的处理流程（6 步）

1. 停止调度：CALL DBMS_SCHEDULER.DISABLE('MVIEW_REFRESH$J_xxx');
2. 删除 MLOG：DROP MATERIALIZED VIEW LOG ON orders; / DROP MATERIALIZED VIEW LOG ON items;
3. 修改列定义：ALTER TABLE orders MODIFY amount DECIMAL(14,2);
4. 重建 MLOG：CREATE MATERIALIZED VIEW LOG ON orders WITH PRIMARY KEY, ROWID, SEQUENCE (...) INCLUDING NEW VALUES;
5. 全量刷新：CALL DBMS_MVIEW.REFRESH('mv_orders_items', 'C');（MLOG 重建后丢失增量记录，必须全量刷新）
6. 恢复调度：CALL DBMS_SCHEDULER.ENABLE('MVIEW_REFRESH$J_xxx');

六、enable_mlog_auto_maintenance 参数实验

6.1 参数说明

SHOW PARAMETERS LIKE 'enable_mlog_auto_maintenance';

6.2 开启后的效果

关键发现： 开启 enable_mlog_auto_maintenance = True 后，创建增量刷新物化视图时不需要手动创建 MLOG，系统会自动管理 MLOG 的创建和维护。

-- 直接创建物化视图（不手动建 MLOG）
CREATE MATERIALIZED VIEW mv_orders_items
    REFRESH FAST ON DEMAND
    START WITH NOW() NEXT NOW() + INTERVAL 1 MINUTE
    ENABLE QUERY REWRITE
    AS SELECT ... FROM orders o JOIN items i ON ...;
-- 成功创建，无需预先 CREATE MATERIALIZED VIEW LOG

对比：

• 关闭时：必须先手动 CREATE MATERIALIZED VIEW LOG，再创建 MV
• 开启时：系统自动创建和维护 MLOG，简化了操作流程

七、实时物化视图创建与对比

7.1 创建实时物化视图

CREATE MATERIALIZED VIEW mv_orders_items_rt
    REFRESH FAST ON DEMAND
    ENABLE ON QUERY COMPUTATION    -- 关键：启用实时查询计算
    AS SELECT ... FROM orders o JOIN items i ON ...;

7.2 对比普通 MV 与实时 MV

SELECT mview_name, refresh_method, rewrite_enabled,
       on_query_computation, refresh_dop, staleness
FROM   oceanbase.dba_mviews
WHERE  mview_name IN ('mv_orders_items', 'mv_orders_items_rt');

关键差异：

• on_query_computation：实时 MV 为 Y，查询时会实时计算未刷新的增量变更；普通 MV 为 N
• refresh_dop：实时 MV 为 0（由系统自动管理，不可手动指定）；普通 MV 可手动设置

八、MLOG 清理机制观测

8.1 实验过程

-- 灌入数据后查看 MLOG
SELECT COUNT(*) FROM mlog$_orders;  -- 50000 行
SELECT COUNT(*) FROM mlog$_items;   -- 3 行

-- 手动触发增量刷新
CALL DBMS_MVIEW.REFRESH('mv_orders_items', 'F');  -- 1.595s

-- 立即查看 MLOG（刷新后）
SELECT COUNT(*) FROM mlog$_orders;  -- 仍然 50000 行！
SELECT COUNT(*) FROM mlog$_items;   -- 仍然 3 行！

关键发现： 增量刷新完成后，MLOG 数据没有立即被清理。

8.2 延迟清理

-- 过一段时间后再查
SELECT COUNT(*) FROM mlog$_orders;  -- 0 行（已清理）
SELECT COUNT(*) FROM mlog$_items;   -- 0 行（已清理）

结论： MLOG 的清理是异步延迟的，不在刷新事务内同步完成。刷新完成后，系统会在后台异步清理已消费的 MLOG 记录。

8.3 刷新统计中的变化量验证

SELECT mv_owner, refresh_id, mv_name, tbl_name,
       num_rows_ins, num_rows_upd, num_rows_del, num_rows
FROM   oceanbase.dba_mvref_change_stats
WHERE  mv_name = 'mv_orders_items'
ORDER  BY refresh_id DESC;

关键记录对比：

分析：

• num_rows_ins 表示本次刷新实际应用的增量行数
• num_rows 表示 MLOG 中待处理的总行数
• 当 num_rows_ins = 0 但 num_rows > 0 时（如 refresh_id 298329），说明 MLOG 数据还在但已被标记为已消费，等后台异步清理

九、observer.log 日志观测（全量刷新）

9.1 获取 trace_id

CALL DBMS_MVIEW.REFRESH('mv_orders_items', 'C');
SELECT last_trace_id();
-- YB42C0A8055F-0006559633DE7958-0-0

9.2 observer.log 中的刷新日志

[17:15:53.583] mview complete refresh success(arg={
  tenant_id:1014, table_id:500044, parallelism:4,
  last_refresh_scn:1783761310230412000,
  target_data_sync_scn:1783761352019617000,
  use_direct_load_for_complete_refresh:true,
  direct_dep_cnt:2,
  select_sql:"select ... from (orders as of snapshot ... join items as of snapshot ...)"
}, res={task_id:305871, trace_id:YB42C0A8055F-0006559633DE7958-0-0})

[17:15:53.583] mview refresh finish(ret=0, ret="OB_SUCCESS", param_={
  tenant_id:1014, mview_id:500044, refresh_id:305861,
  refresh_method:1, retry_id:0, parallel:0,
  target_data_sync_scn:1783761352019617000
})

日志字段解读：

关键发现：

• 全量刷新使用 as of snapshot 语法读取基表的一致性快照
• 采用 direct load（旁路导入）提升全量刷新性能
• 可通过 trace_id 在 observer.log 中串联完整的刷新执行链路

9.3 刷新统计验证（dba_mvref_stats）

SELECT * FROM oceanbase.DBA_MVREF_STATS WHERE refresh_id=305861;

十、核心知识点总结