This is an automated email from the ASF dual-hosted git repository.
morningman pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/doris-website.git
The following commit(s) were added to refs/heads/master by this push:
new a2ef1de48e2 [doc](materialized-view) document IVM auto refresh
triggers and minimum interval (#4145)
a2ef1de48e2 is described below
commit a2ef1de48e2693aec892048512b1fffa553c21fa
Author: Mingyu Chen (Rayner) <[email protected]>
AuthorDate: Wed Sep 16 13:49:56 2026 +0800
[doc](materialized-view) document IVM auto refresh triggers and minimum
interval (#4145)
## What
The IVM page
(`query-acceleration/materialized-view/async-materialized-view/incremental-materialized-view`,
added in #4141) did not explain how to set up automatic refresh for an
incremental materialized view, nor what the minimum refresh interval is.
This PR adds a **Setting the automatic refresh interval / 设置自动刷新间隔**
subsection to both the EN and zh-CN pages, plus matching FAQ rows, a
best-practice item and cross-links.
## Content (verified against the FE implementation on
`branch-incremental-computation`)
- IVM reuses the common MV triggers: `ON MANUAL` (default), `ON SCHEDULE
EVERY <n> <unit> [STARTS '<time>']`, `ON COMMIT` (`DorisParser.g4`
`refreshTrigger`).
- **Minimum scheduled interval is `EVERY 1 MINUTE`**: units are
`MINUTE/HOUR/DAY/WEEK`; `SECOND` fails with `interval time unit can not
be second` unless the test-only FE option
`enable_job_schedule_second_for_test` is set
(`LogicalPlanBuilder.visitMvRefreshUnit`,
`MTMVRefreshSchedule.validate`).
- `STARTS` must be later than now; without it the first run is one
interval after creation and later runs are aligned to fixed multiples of
the interval (`TimerDefinition.initParams`,
`JobExecutionConfiguration`).
- Scheduled / on-commit tasks run the MV's persisted policy
(`INCREMENTAL`, `INCREMENTAL FALLBACK`, `AUTO`)
(`MTMVTaskContext.forMvDefault`, `MTMVTask.resolveRefreshRequest`).
- The first automatic refresh builds the `COMPLETE` baseline by itself
(`MTMVTask.shouldUseCompleteForInitialIvmRefresh`).
- Tasks of one MV run serially; at most one running + one waiting
automatic task, surplus triggers are skipped and counted in
`async_materialized_view_task_skip_num`
(`MTMVJob.isReadyForScheduling`).
- `ON COMMIT` is not triggered by tables in `excluded_trigger_tables`.
- The trigger can be changed with `ALTER MATERIALIZED VIEW ... REFRESH
ON ...`; repeating `INCREMENTAL` in `ALTER` is rejected
(`AlterMTMVRefreshInfo.validateRefreshMethodCompat`).
## Versions
- [x] dev
- [ ] 4.x
- [ ] 3.x
- [ ] 2.1
## Languages
- [x] Chinese
- [x] English
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: morningman <[email protected]>
Co-authored-by: Claude Opus 5 (1M context) <[email protected]>
---
.../incremental-materialized-view.md | 70 +++++++++++++++++++---
.../incremental-materialized-view.md | 70 +++++++++++++++++++---
2 files changed, 124 insertions(+), 16 deletions(-)
diff --git
a/docs/query-acceleration/materialized-view/async-materialized-view/incremental-materialized-view.md
b/docs/query-acceleration/materialized-view/async-materialized-view/incremental-materialized-view.md
index ad5d2a31c77..5b22a95b107 100644
---
a/docs/query-acceleration/materialized-view/async-materialized-view/incremental-materialized-view.md
+++
b/docs/query-acceleration/materialized-view/async-materialized-view/incremental-materialized-view.md
@@ -11,6 +11,8 @@
"materialized view incremental maintenance",
"materialized view row-level update",
"IVM incremental refresh",
+ "IVM refresh interval",
+ "IVM scheduled refresh",
"IVM fallback",
"IvmFallbackReason",
"internal Table Stream",
@@ -163,7 +165,7 @@ INSERT INTO orders VALUES
### Step 2: Create the IVM
-Specify `REFRESH INCREMENTAL` in `CREATE MATERIALIZED VIEW`. This example also
specifies `FALLBACK`, so that Doris can fall back to a partition refresh or a
complete refresh when a change cannot be computed incrementally in a safe way.
+Specify `REFRESH INCREMENTAL` in `CREATE MATERIALIZED VIEW`. This example also
specifies `FALLBACK`, so that Doris can fall back to a partition refresh or a
complete refresh when a change cannot be computed incrementally in a safe way.
The trigger is `ON MANUAL` so that each refresh can be observed step by step;
production views usually switch to a scheduled or on-commit trigger, see
[Setting the automatic refresh
interval](#setting-the-automatic-refresh-interval).
```sql
CREATE MATERIALIZED VIEW orders_by_status
@@ -317,7 +319,7 @@ Some aggregate functions cannot safely derive the new
result from the current de
Strict `INCREMENTAL` fails in these cases; `INCREMENTAL FALLBACK` falls back
to `COMPLETE`.
<!-- Knowledge type: Runtime behavior / Failure handling -->
-<!-- Use cases: Configuring the refresh strategy / Diagnosing IVM fallback /
Rebuilding the baseline -->
+<!-- Use cases: Configuring the refresh strategy / Automatic refresh interval
/ Diagnosing IVM fallback / Rebuilding the baseline -->
## Refresh and fallback
@@ -331,6 +333,55 @@ Strict `INCREMENTAL` fails in these cases; `INCREMENTAL
FALLBACK` falls back to
| `REFRESH PARTITIONS [FALLBACK]` | Requires the materialized view to define
`PARTITION BY` | Recomputes the changed partitions; with `FALLBACK`, can fall
back to a complete refresh |
| `REFRESH COMPLETE` | Does not create IVM metadata | Always refreshes
completely |
+### Setting the automatic refresh interval
+
+IVM reuses the trigger methods of asynchronous materialized views and has no
trigger syntax of its own. Specify the trigger in the `ON` clause after
`REFRESH INCREMENTAL [FALLBACK]`:
+
+| Trigger | Syntax | Description |
+|---|---|---|
+| Manual | `ON MANUAL` | Default. Refreshes only when `REFRESH MATERIALIZED
VIEW` is executed |
+| Scheduled | `ON SCHEDULE EVERY <interval> <unit> [STARTS '<start_time>']` |
Runs an incremental refresh automatically at a fixed interval |
+| On commit | `ON COMMIT` | Runs an incremental refresh automatically after a
load transaction commits on a base table |
+
+The rules for the scheduled interval are:
+
+- `<interval>` must be a positive integer, and `<unit>` can be `MINUTE`,
`HOUR`, `DAY` or `WEEK`.
+- **The minimum refresh interval is `EVERY 1 MINUTE`.** Specifying `SECOND`
fails with `interval time unit can not be second`. The FE option
`enable_job_schedule_second_for_test` allows second-level intervals, but it is
for testing only and must not be enabled in production.
+- `STARTS` sets the first scheduling time in the format `'yyyy-MM-dd
HH:mm:ss'` and must be later than the current time. Without it, the first
refresh runs one interval after the materialized view is created. Later runs
are fixed at the first scheduling time plus whole multiples of the interval,
regardless of when the previous task finished.
+
+The following example runs an incremental refresh every 5 minutes and allows
fallback when a change cannot be computed incrementally:
+
+```sql
+CREATE MATERIALIZED VIEW orders_by_status
+BUILD IMMEDIATE
+REFRESH INCREMENTAL FALLBACK ON SCHEDULE EVERY 5 MINUTE
+DISTRIBUTED BY RANDOM BUCKETS 1
+PROPERTIES (
+ "replication_num" = "1"
+)
+AS
+SELECT
+ order_status,
+ COUNT(*) AS order_count,
+ SUM(amount) AS total_amount
+FROM orders
+GROUP BY order_status;
+```
+
+Scheduled and on-commit tasks run with the refresh strategy defined when the
materialized view was created: `INCREMENTAL` only tries IVM, `INCREMENTAL
FALLBACK` tries IVM first and then falls back according to the reason, and
`AUTO` tries IVM, partition refresh and complete refresh in turn. Automatically
triggered tasks also behave as follows:
+
+- **The first automatic refresh builds the baseline by itself.** If the
materialized view has never been refreshed successfully (for example, it was
created with `BUILD DEFERRED` and not refreshed yet), the first scheduled or
on-commit task automatically runs `COMPLETE` to build the full baseline; you do
not need to run `COMPLETE` by hand. Later tasks then refresh incrementally.
+- **Refresh tasks of one materialized view run serially, and surplus triggers
are skipped.** At most one running and one waiting automatically triggered task
are kept. When the interval is shorter than the duration of a single refresh,
or base tables commit very frequently under `ON COMMIT`, new triggers are
skipped and the FE metric `async_materialized_view_task_skip_num` increases.
The waiting task consumes all accumulated changes in one run, so no change is
lost, but the actual refres [...]
+- **`ON COMMIT` is triggered only by base tables that participate in
incremental maintenance.** Commits on tables listed in
`excluded_trigger_tables` do not trigger a refresh, see
[excluded_trigger_tables](#excluded_trigger_tables).
+
+When changing the trigger, specify only the `ON` clause and do not repeat
`INCREMENTAL`. The refresh method of an IVM cannot be changed with `ALTER`, so
`ALTER MATERIALIZED VIEW ... REFRESH INCREMENTAL ...` is rejected; changing
only the trigger is allowed, and Doris recreates the scheduling job with the
new trigger:
+
+```sql
+ALTER MATERIALIZED VIEW orders_by_status REFRESH ON SCHEDULE EVERY 1 MINUTE;
+ALTER MATERIALIZED VIEW orders_by_status REFRESH ON COMMIT;
+ALTER MATERIALIZED VIEW orders_by_status REFRESH ON MANUAL;
+```
+
### Overriding the refresh method manually
After an IVM is created, you can run any of the following as needed:
@@ -513,7 +564,7 @@ For all materialized view properties, see [CREATE ASYNC
MATERIALIZED VIEW](../..
- IVM can only be enabled when the materialized view is created. You cannot
turn a regular materialized view into an IVM with `ALTER MATERIALIZED VIEW`,
nor change an IVM to another default refresh method. To switch, recreate the
materialized view.
- Enabling Row Binlog adds write and storage overhead. Unique Key MoW tables
also need to read and store the values before each update. Enable it only for
base tables that really need IVM, and evaluate load throughput with realistic
workloads before going to production.
-- IVM still refreshes through asynchronous tasks and does not provide
real-time consistency with base table transactions. Refresh latency depends on
the trigger method, queueing time and the execution time of the delta plan.
+- IVM still refreshes through asynchronous tasks and does not provide
real-time consistency with base table transactions. Refresh latency depends on
the trigger method, queueing time and the execution time of the delta plan. The
minimum scheduled interval is 1 minute, see [Setting the automatic refresh
interval](#setting-the-automatic-refresh-interval).
- Complex nested outer joins enlarge the delta plan, especially complex
subtrees on the null-producing side. When planning or refresh becomes too
expensive, simplify the joins or materialize the complex subtree as a
lower-level IVM first.
- `MIN`, `MAX` and Bitmap aggregations require a complete recomputation in
some delete scenarios. In production, use `INCREMENTAL FALLBACK` or `AUTO` and
monitor `IvmFallbackReason`.
- The table model, column type, schema change and delete restrictions of Row
Binlog apply directly to IVM. See [Supported scope and limitations of Row
Binlog](../../../data-operate/incremental/row-binlog#supported-scope-and-limitations).
@@ -529,6 +580,8 @@ When creation fails, a refresh falls back, or the data is
not updated, use the t
|---|---|
| `CREATE MATERIALIZED VIEW ... REFRESH INCREMENTAL` fails | Check that
`enable_feature_binlog` and `enable_table_stream` are enabled on the FEs, that
the base tables meet the table model and Row Binlog requirements, and that the
definition SQL is within the IVM support scope |
| A strict incremental refresh asks for a baseline rebuild | Run a `COMPLETE`
or `AUTO` refresh to build a new full baseline, then run the strict incremental
refresh again |
+| `ON SCHEDULE EVERY 30 SECOND` fails with `interval time unit can not be
second` | The minimum scheduled interval is `EVERY 1 MINUTE`, and the unit can
only be `MINUTE`, `HOUR`, `DAY` or `WEEK`. Use `ON COMMIT` when lower latency
is needed, see [Setting the automatic refresh
interval](#setting-the-automatic-refresh-interval) |
+| The actual latency of scheduled refreshes is longer than the interval |
Tasks of one materialized view run serially, and surplus triggers are skipped
when a single refresh takes longer than the interval. Check task durations in
`tasks("type"="mv")` and the FE metric `async_materialized_view_task_skip_num`,
then lengthen the interval, simplify the definition, or give the refresh more
resources through `workload_group` |
| The refresh task falls back to `COMPLETE` | Query `IvmFallbackReason` in
`tasks("type"="mv")` and handle it according to the reasons in [Fallback
order](#fallback-order) |
| The view is not updated after an excluded base table changes on its own |
Tables in `excluded_trigger_tables` do not trigger refreshes on their own. Wait
for a refresh triggered by other base tables, or adjust the property and
rebuild the baseline as prompted |
| Can internal Streams be consumed or reset manually | No. Internal Streams
are reserved for IVM; Doris manages their lifecycle and consumption offsets |
@@ -540,11 +593,12 @@ When creation fails, a refresh falls back, or the data is
not updated, use the t
1. **Compare the number of changed rows with the partition size first.**
Prefer IVM when changes are a small share of a partition; when changes cover
most of a partition, `PARTITIONS` may be simpler.
2. **Enable safe fallback in production.** Use `INCREMENTAL FALLBACK` or
`AUTO` so that deletes or baseline problems do not leave refreshes failing for
a long time.
-3. **Build the full baseline first.** Run `COMPLETE` after creation, verify
the result, then start incremental refreshes.
-4. **Use Unique Key MoW for update and delete workloads.** Duplicate Key
tables only suit append-only data.
-5. **Isolate resources for refresh tasks.** Use `workload_group` to keep
complex delta plans from competing with online queries.
-6. **Monitor tasks and Stream backlog.** Watch `tasks("type"="mv")`,
`mv_infos` and `information_schema.table_stream_consumption` together.
-7. **Review fallback reasons regularly.** Occasional fallbacks protect
correctness; continuous fallbacks indicate that the query shape, Binlog
continuity or the baseline needs attention.
+3. **Choose the trigger and interval from the refresh duration.** The minimum
scheduled interval is 1 minute, and the interval should exceed the duration of
a single incremental refresh under normal load; use `ON COMMIT` when lower
latency is needed and base tables do not commit too frequently.
+4. **Build the full baseline first.** Run `COMPLETE` after creation, verify
the result, then start incremental refreshes.
+5. **Use Unique Key MoW for update and delete workloads.** Duplicate Key
tables only suit append-only data.
+6. **Isolate resources for refresh tasks.** Use `workload_group` to keep
complex delta plans from competing with online queries.
+7. **Monitor tasks and Stream backlog.** Watch `tasks("type"="mv")`,
`mv_infos` and `information_schema.table_stream_consumption` together.
+8. **Review fallback reasons regularly.** Occasional fallbacks protect
correctness; continuous fallbacks indicate that the query shape, Binlog
continuity or the baseline needs attention.
<!-- Knowledge type: Step-by-step guide -->
<!-- Use cases: Cleaning up the example environment -->
diff --git
a/i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/materialized-view/async-materialized-view/incremental-materialized-view.md
b/i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/materialized-view/async-materialized-view/incremental-materialized-view.md
index e6e3e1d1134..02a434f435b 100644
---
a/i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/materialized-view/async-materialized-view/incremental-materialized-view.md
+++
b/i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/materialized-view/async-materialized-view/incremental-materialized-view.md
@@ -11,6 +11,8 @@
"物化视图增量维护",
"物化视图行级更新",
"IVM 增量刷新",
+ "IVM 刷新间隔",
+ "IVM 定时刷新",
"IVM 回退",
"IvmFallbackReason",
"内部 Table Stream",
@@ -163,7 +165,7 @@ INSERT INTO orders VALUES
### 第 2 步：创建 IVM
-在 `CREATE MATERIALIZED VIEW` 中指定 `REFRESH INCREMENTAL`。本例同时指定
`FALLBACK`，当某次变化无法安全地增量计算时，Doris 可以回退到分区刷新或完整刷新。
+在 `CREATE MATERIALIZED VIEW` 中指定 `REFRESH INCREMENTAL`。本例同时指定
`FALLBACK`，当某次变化无法安全地增量计算时，Doris 可以回退到分区刷新或完整刷新。触发方式使用 `ON
MANUAL`，便于逐步观察每次刷新的结果；生产环境通常改为定时或提交触发，见 [设置自动刷新间隔](#设置自动刷新间隔)。
```sql
CREATE MATERIALIZED VIEW orders_by_status
@@ -317,7 +319,7 @@ IVM 支持以下聚合函数，参数可以是列或确定性表达式：
严格 `INCREMENTAL` 会在这些情况下失败；`INCREMENTAL FALLBACK` 会回退到 `COMPLETE`。
<!-- 知识类型: 运行机制 / 故障处理 -->
-<!-- 适用场景: 刷新策略配置 / IVM 回退排查 / 基线恢复 -->
+<!-- 适用场景: 刷新策略配置 / 自动刷新间隔 / IVM 回退排查 / 基线恢复 -->
## 刷新和回退
@@ -331,6 +333,55 @@ IVM 支持以下聚合函数，参数可以是列或确定性表达式：
| `REFRESH PARTITIONS [FALLBACK]` | 要求物化视图定义 `PARTITION BY` | 重算变化分区；指定
`FALLBACK` 后可回退到完整刷新 |
| `REFRESH COMPLETE` | 不创建 IVM 元数据 | 始终完整刷新 |
+### 设置自动刷新间隔
+
+IVM 复用异步物化视图的触发方式，没有单独的触发语法。在 `REFRESH INCREMENTAL [FALLBACK]` 之后通过 `ON` 子句指定：
+
+| 触发方式 | 语法 | 说明 |
+|---|---|---|
+| 手动触发 | `ON MANUAL` | 默认值。只在执行 `REFRESH MATERIALIZED VIEW` 时刷新 |
+| 定时触发 | `ON SCHEDULE EVERY <interval> <unit> [STARTS '<start_time>']` |
按固定间隔自动执行增量刷新 |
+| 提交触发 | `ON COMMIT` | 基表导入事务提交后自动执行增量刷新 |
+
+定时触发的间隔规则如下：
+
+- `<interval>` 必须是正整数，`<unit>` 支持 `MINUTE`、`HOUR`、`DAY`、`WEEK`。
+- **最小刷新间隔为 `EVERY 1 MINUTE`。** 指定 `SECOND` 会报错 `interval time unit can not be
second`。FE 配置 `enable_job_schedule_second_for_test` 可以放开秒级间隔，但该配置仅供测试，生产环境不要开启。
+- `STARTS` 指定首次调度时间，格式为 `'yyyy-MM-dd
HH:mm:ss'`，必须晚于当前时间。不指定时，第一次刷新在创建物化视图后经过一个间隔执行。后续调度时间固定为首次调度时间加整数倍间隔，不受上一次任务结束时间影响。
+
+下面的示例每 5 分钟执行一次增量刷新，无法增量计算时允许回退：
+
+```sql
+CREATE MATERIALIZED VIEW orders_by_status
+BUILD IMMEDIATE
+REFRESH INCREMENTAL FALLBACK ON SCHEDULE EVERY 5 MINUTE
+DISTRIBUTED BY RANDOM BUCKETS 1
+PROPERTIES (
+ "replication_num" = "1"
+)
+AS
+SELECT
+ order_status,
+ COUNT(*) AS order_count,
+ SUM(amount) AS total_amount
+FROM orders
+GROUP BY order_status;
+```
+
+定时触发和提交触发的任务按物化视图创建时定义的刷新策略执行：`INCREMENTAL` 只尝试 IVM，`INCREMENTAL FALLBACK` 先尝试
IVM 再按原因回退，`AUTO` 依次尝试 IVM、分区刷新和完整刷新。自动触发的任务还有以下行为：
+
+- **首次自动刷新会自动建立基线。** 物化视图还没有刷新成功过时（例如使用 `BUILD DEFERRED`
创建后尚未刷新），第一次定时或提交触发的任务会自动执行 `COMPLETE` 建立完整基线，不需要手工执行 `COMPLETE`；之后的任务才执行增量刷新。
+- **同一物化视图的刷新任务串行执行，多余的触发会被跳过。** 自动触发的任务最多保留一个正在运行和一个等待执行。当刷新间隔短于单次刷新耗时，或者 `ON
COMMIT` 下基表提交非常频繁时，新的触发会被跳过，FE 指标 `async_materialized_view_task_skip_num`
累加。等待中的任务执行时会一次性消费积累的全部变化，因此不会丢失变化，但实际刷新延迟会大于设定间隔。选择间隔时，应保证正常负载下单次增量刷新能在一个间隔内完成。
+- **`ON COMMIT` 只由参与增量维护的基表触发。** `excluded_trigger_tables` 中的基表提交不触发刷新，详见
[excluded_trigger_tables](#excluded_trigger_tables)。
+
+修改触发方式时只指定 `ON` 子句，不要重复写 `INCREMENTAL`。IVM 的刷新方式不能通过 `ALTER` 修改，`ALTER
MATERIALIZED VIEW ... REFRESH INCREMENTAL ...` 会被拒绝；只修改触发方式是允许的，修改后 Doris
会按新的触发方式重建调度任务：
+
+```sql
+ALTER MATERIALIZED VIEW orders_by_status REFRESH ON SCHEDULE EVERY 1 MINUTE;
+ALTER MATERIALIZED VIEW orders_by_status REFRESH ON COMMIT;
+ALTER MATERIALIZED VIEW orders_by_status REFRESH ON MANUAL;
+```
+
### 手动覆盖刷新方式
IVM 创建后，可以根据需要执行：
@@ -513,7 +564,7 @@ PROPERTIES (
- IVM 只能在创建物化视图时启用。不能通过 `ALTER MATERIALIZED VIEW` 把普通物化视图改为 IVM，也不能把 IVM
改为其他默认刷新方式。需要切换时，请重建物化视图。
- 开启 Row Binlog 会增加写入和存储开销。Unique Key MoW 表还需要读取并保存更新前的值。只为确实需要 IVM
的基表开启，并在生产上线前使用真实负载评估导入吞吐。
-- IVM 仍通过异步任务刷新，不提供与基表事务同步的实时一致性。刷新延迟取决于触发方式、排队时间和增量计划的执行时间。
+- IVM 仍通过异步任务刷新，不提供与基表事务同步的实时一致性。刷新延迟取决于触发方式、排队时间和增量计划的执行时间。定时触发的最小间隔为 1 分钟，见
[设置自动刷新间隔](#设置自动刷新间隔)。
- 复杂的嵌套外连接会扩大增量计划，尤其是空值产生端的复杂子树。遇到规划或刷新开销过高时，可以简化 Join，或者先把复杂子树物化为下层 IVM。
- `MIN`、`MAX` 和 Bitmap 聚合在部分删除场景下需要完整重算。生产环境建议使用 `INCREMENTAL FALLBACK` 或
`AUTO`，并监控 `IvmFallbackReason`。
- Row Binlog 的表模型、列类型、Schema Change 和删除行为限制会直接影响 IVM，详见 [Row Binlog
的支持范围与限制](../../../data-operate/incremental/row-binlog#支持范围与限制)。
@@ -529,6 +580,8 @@ PROPERTIES (
|---|---|
| `CREATE MATERIALIZED VIEW ... REFRESH INCREMENTAL` 创建失败 | 检查 FE 是否开启
`enable_feature_binlog` 和 `enable_table_stream`，基表是否满足模型与 Row Binlog 要求，以及定义
SQL 是否在 IVM 支持范围内 |
| 严格增量刷新提示重建基线 | 执行 `COMPLETE` 或 `AUTO` 刷新，建立新的完整基线后再执行严格增量刷新 |
+| `ON SCHEDULE EVERY 30 SECOND` 报错 `interval time unit can not be second` |
定时刷新的最小间隔是 `EVERY 1 MINUTE`，单位只支持 `MINUTE`、`HOUR`、`DAY`、`WEEK`。需要更低延迟时改用 `ON
COMMIT`，见 [设置自动刷新间隔](#设置自动刷新间隔) |
+| 定时刷新的实际延迟大于设定间隔 | 同一物化视图的任务串行执行，单次刷新耗时超过间隔时多余触发会被跳过。检查 `tasks("type"="mv")`
中的任务耗时和 FE 指标 `async_materialized_view_task_skip_num`，拉长间隔、简化定义或通过
`workload_group` 增加刷新资源 |
| 刷新任务回退到 `COMPLETE` | 查询 `tasks("type"="mv")` 的 `IvmFallbackReason`，并根据
[回退顺序](#回退顺序) 中的原因处理 |
| 被排除的基表单独变化后，视图数据未更新 | `excluded_trigger_tables`
中的表不会独立触发刷新。等待其他基表变化触发刷新，或调整属性并按提示重建基线 |
| 能否手工消费或重置内部 Stream | 不能。内部 Stream 仅供 IVM 使用，由 Doris 管理生命周期和消费位点 |
@@ -540,11 +593,12 @@ PROPERTIES (
1. **先比较变化行数和分区大小。** 变化只占分区很小比例时优先考虑 IVM；变化覆盖大部分分区时，`PARTITIONS` 可能更简单。
2. **生产环境启用安全回退。** 使用 `INCREMENTAL FALLBACK` 或 `AUTO`，避免删除或基线问题让刷新长期失败。
-3. **先建立完整基线。** 创建后先运行 `COMPLETE`，确认结果正确，再开始增量刷新。
-4. **更新和删除场景使用 Unique Key MoW。** Duplicate Key 表只适合追加型数据。
-5. **为刷新任务隔离资源。** 通过 `workload_group` 避免复杂增量计划与在线查询争抢资源。
-6. **监控任务和 Stream 积压。** 同时观察 `tasks("type"="mv")`、`mv_infos` 和
`information_schema.table_stream_consumption`。
-7. **定期检查回退原因。** 偶发回退可以保证正确性；持续回退说明查询形态、Binlog 连续性或基线需要处理。
+3. **按刷新耗时选择触发方式和间隔。** 定时触发的最小间隔为 1 分钟，间隔应大于正常负载下单次增量刷新的耗时；需要更低延迟且基表提交不频繁时使用
`ON COMMIT`。
+4. **先建立完整基线。** 创建后先运行 `COMPLETE`，确认结果正确，再开始增量刷新。
+5. **更新和删除场景使用 Unique Key MoW。** Duplicate Key 表只适合追加型数据。
+6. **为刷新任务隔离资源。** 通过 `workload_group` 避免复杂增量计划与在线查询争抢资源。
+7. **监控任务和 Stream 积压。** 同时观察 `tasks("type"="mv")`、`mv_infos` 和
`information_schema.table_stream_consumption`。
+8. **定期检查回退原因。** 偶发回退可以保证正确性；持续回退说明查询形态、Binlog 连续性或基线需要处理。
<!-- 知识类型: 操作步骤 -->
<!-- 适用场景: 示例环境清理 -->
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
