给大表补几条新记录，听起来像只改通讯录最后一页；可实际执行时，系统可能先翻完整本、逐条核对，再重新装订。Reddit 用户 Traditional-Cry-1334 就遇到这种落差：dbt 模型已声明为增量更新，也尝试了分区和增量谓词，Trino 里的 MERGE 仍很慢，还频繁因内存不足或分区错误失败。
问题在于，“增量”只说明 dbt 生成新增或变化的数据，不代表写入过程同样轻量。据 dbt-trino 官方文档，其 merge 策略会按 unique_key——用于识别同一条记录的唯一键——生成 MERGE，对旧行更新、新行插入；文档也提醒，部分 Trino connector（把 Trino 的读写真正落实到 Iceberg、Hive 或数据库的连接层）支持有限或完全不支持 MERGE。
据 Trino 官方文档，MERGE 还要连接来源表与目标表，检查重复匹配；更新可能按分区或分桶规则在工作节点间重新分发。有些 connector 甚至会把一次 UPDATE 拆成 DELETE 和 INSERT。于是，输入数据虽少，目标表扫描、数据搬运和文件改写仍可能很重。这个案例没有给出表规模、connector 或执行计划，无法锁定单一原因；但它提醒团队，排查重点应从 dbt 的“增量”标签下沉到 MERGE 执行、分区裁剪和 connector 的实际能力。