Snowflake CHANGES机制性能疑问：为何自连接且慢于Merge？

一、CHANGES子句比Merge慢的核心原因 #

1. 机制固有开销：CHANGES的核心逻辑是对比表在两个时间点的快照来识别变更，因此必须扫描两个版本的表数据做自连接——这是它实现增量变更识别的必要步骤，不可能仅扫描一次表就完成。你在执行计划中看到的自连接，正是Snowflake用来比对新旧版本、标记INSERT/UPDATE/DELETE操作的核心逻辑。
2. Merge执行路径更高效：Merge直接基于源表和目标表的当前状态做匹配，无需回溯历史版本。如果目标表有合适的聚类键、分区键或开启了搜索优化服务，Snowflake可以快速定位需要更新/插入的行，大幅减少无效扫描。而CHANGES无论你需要什么类型的变更，都得先加载两个快照再做比对，大表场景下这个额外开销会非常显著。

二、如何用CHANGES机制实现源表的删除和更新操作 #

要利用CHANGES同步删改，核心是通过CHANGE_TYPE字段识别操作类型，再结合Merge实现批量同步：

1. 先开启源表的变更跟踪 #

这是使用CHANGES子句的前提，执行以下语句开启：

ALTER TABLE YOUR_SOURCE_TABLE SET CHANGE_TRACKING = TRUE;

2. 提取源表的增量变更 #

推荐用增量模式配合书签（自动记录上次查询位置）获取变更，避免重复扫描历史数据：

SELECT
    PRIMARY_KEY_COL, -- 必须保留主键，用于匹配目标表行
    COL1, COL2, -- 需要同步的业务字段
    CHANGE_TYPE -- 标记操作类型：INSERT/UPDATE/DELETE
FROM YOUR_SOURCE_TABLE
CHANGES(INCREMENTAL => TRUE); -- 自动获取从上一次查询以来的所有变更

若需指定时间范围，可替换为：

CHANGES(START => '2024-01-01 00:00:00'::TIMESTAMP, END => CURRENT_TIMESTAMP)

3. 用Merge将变更同步到目标表 #

将上述查询作为数据源，编写Merge语句处理不同操作类型：

MERGE INTO YOUR_TARGET_TABLE tgt
USING (
    SELECT
        PRIMARY_KEY_COL,
        COL1, COL2,
        CHANGE_TYPE
    FROM YOUR_SOURCE_TABLE
    CHANGES(INCREMENTAL => TRUE)
) src
ON tgt.PRIMARY_KEY_COL = src.PRIMARY_KEY_COL
-- 处理DELETE：匹配到主键且变更类型为DELETE时删除目标表行
WHEN MATCHED AND src.CHANGE_TYPE = 'DELETE' THEN DELETE
-- 处理UPDATE：匹配到主键且变更类型为UPDATE时更新字段
WHEN MATCHED AND src.CHANGE_TYPE = 'UPDATE' THEN UPDATE SET
    tgt.COL1 = src.COL1,
    tgt.COL2 = src.COL2
-- 处理INSERT：未匹配到主键且变更类型为INSERT/UPDATE时插入新行
WHEN NOT MATCHED AND src.CHANGE_TYPE IN ('INSERT', 'UPDATE') THEN INSERT (PRIMARY_KEY_COL, COL1, COL2)
VALUES (src.PRIMARY_KEY_COL, src.COL1, src.COL2);

4. 优化CHANGES查询性能 #

• 只提取需要的字段，避免SELECT *带来的不必要数据传输。
• 提前用WHERE CHANGE_TYPE过滤掉不需要的变更类型，减少Merge的处理数据量。
• 若源表数据量极大，可先将CHANGES的结果写入小的临时staging表，再基于该表做Merge，进一步降低开销。

三、原克隆staging层Merge流程的优化建议 #

你之前的流程成本高，大概率是因为克隆的staging表丢失了原表的关键属性：

• 克隆时加上INCLUDING CLUSTERING，保留原表的聚类键，让Merge时能快速定位行：

  CREATE OR REPLACE TABLE STAGING_TABLE CLONE YOUR_TARGET_TABLE INCLUDING CLUSTERING;
  

• 确保Merge的ON子句使用主键或聚类键，让Snowflake能利用聚类索引减少扫描范围。

内容的提问来源于stack exchange，提问作者RDK