提高动态表增量刷新比例

看到某次刷新的

refresh_mode

refresh_mode

是

FULL

FULL

不用慌。动态表每次刷新时，引擎会按成本自动在增量和全量之间选择——走没走增量，不能只看你写的 SQL 算子来猜，要以刷新历史里的

refresh_mode

refresh_mode

为准。本文讲怎么判断、什么情况会走全量、以及怎么尽量保住增量。

先学会看刷新模式

用

SHOW DYNAMIC TABLE REFRESH HISTORY

SHOW DYNAMIC TABLE REFRESH HISTORY

看每次刷新，重点是三个字段：

SHOW DYNAMIC TABLE REFRESH HISTORY WHERE name = '<动态表名>' LIMIT 10;

```
refresh_mode
```
refresh_mode
：这次刷新的方式。
- ```
INCREMENTAL
```
  INCREMENTAL
  ：只处理了变化的部分。
- ```
FULL
```
  FULL
  ：整张表重新计算了一遍。
- ```
NO_DATA
```
  NO_DATA
  ：上游没有新变化，这次什么都没算——是正常状态，不是异常。
```
stats
```
stats
：增量刷新改动了多少行，如
```
{"rows_deleted":"1","rows_inserted":"1"}
```
{"rows_deleted":"1","rows_inserted":"1"}
。
```
duration
```
duration
：这次刷新的耗时，用来判断刷新间隔是否够长、有没有积压。

字段全集见查看动态表刷新模式。

别想当然：这些写法仍走增量

最容易踩的误区，是凭"我用了某个算子，所以肯定退全量"下结论。很多被传为"不支持增量"的写法，实际仍然走增量。

以

ORDER BY

ORDER BY

为例：

CREATE TABLE doc_fr_src (id INT, grp STRING, val INT); INSERT INTO doc_fr_src VALUES (1,'A',10),(2,'A',20),(3,'B',30); CREATE DYNAMIC TABLE doc_fr_ordered REFRESH INTERVAL 5 MINUTE VCLUSTER DEFAULT AS SELECT id, val FROM doc_fr_src ORDER BY val; REFRESH DYNAMIC TABLE doc_fr_ordered; -- 新增一行后再刷新 INSERT INTO doc_fr_src VALUES (4,'B',40); REFRESH DYNAMIC TABLE doc_fr_ordered; SHOW DYNAMIC TABLE REFRESH HISTORY WHERE name = 'doc_fr_ordered' LIMIT 2;

两次刷新都是增量：

刷新	refresh_mode	stats
建表后首次	`INCREMENTAL` INCREMENTAL	`{"rows_deleted":"0","rows_inserted":"3"}` {"rows_deleted":"0","rows_inserted":"3"}
新增 1 行后	`INCREMENTAL` INCREMENTAL	`{"rows_deleted":"0","rows_inserted":"1"}` {"rows_deleted":"0","rows_inserted":"1"}

ORDER BY

ORDER BY

并没有让它退全量。同样，窗口聚合

SUM(...) OVER (PARTITION BY ...)

SUM(...) OVER (PARTITION BY ...)

、聚合的撤销（退款把金额减回去）、

ROW_NUMBER()

ROW_NUMBER()

取每键最新（

rn = 1

rn = 1

）这些写法，刷新时也都走增量。所以结论只有一个：别凭算子猜，跑一次看
refresh_mode
refresh_mode
。

什么情况会走全量

走全量有两类原因，性质完全不同。

一、引擎按成本主动选了全量（最常见）。 引擎判断"这次全量比增量更划算"时就会走全量，典型情况是：数据量很小（全量本来就便宜）、单次变更占了全表很大比例、或者多表

JOIN

JOIN

、宽表这类增量代价偏高的场景。这不是"不支持增量"，而是"这次没必要增量"。

一个直接后果：在几行测试数据上很容易看到

FULL

FULL

，到了生产数据量反而走增量。 例如一张两表关联的宽表，建好后第一次变更常常走

FULL

FULL

，之后的小幅变更才转

INCREMENTAL

INCREMENTAL

。所以别用小数据集的刷新模式去推断生产表现。

二、改了定义后的一次重算。 用

CREATE OR REPLACE

CREATE OR REPLACE

改了加工逻辑（改

SELECT

SELECT

、新增计算列、改列类型）后，引擎会触发一次重算来对齐新定义。定义稳定下来之后，后续刷新照常走增量。

💡 提示：

NO_DATA

NO_DATA

不算"走全量"，它表示上游自上次刷新以来没有新变化，这次无需计算。频繁出现

NO_DATA

NO_DATA

往往说明刷新间隔比数据变化频率更短，可以适当调大间隔省成本。

怎么尽量保住增量

用真实数据量评估：别在几行测试数据上判断增量效果，小数据下引擎会主动选全量，看到
```
FULL
```
FULL
是正常的。
让定义稳定：频繁
```
CREATE OR REPLACE
```
CREATE OR REPLACE
改定义会反复触发重算，逻辑定型后再上线。
控制单次变更占比：一次性灌入接近全表规模的数据，会让增量不划算而退全量；细水长流的持续变更最适合增量。
给引擎可利用的聚集性：让
```
JOIN key
```
JOIN key
、
```
GROUP key
```
GROUP key
、分区键能区分冷热数据，引擎才能只碰相关数据。原理见增量计算机制与动态表。
拿不准就跑一次看：以
```
refresh_mode
```
refresh_mode
为准，不要凭算子或旧印象下结论。

提高动态表增量刷新比例

先学会看刷新模式

别想当然：这些写法仍走增量

什么情况会走全量

怎么尽量保住增量

相关文档