ADF复制活动启用Upsert选项时，复制活动结果摘要中Rows Written是否应显示为0？

这问题我之前帮同事排查过类似的，核心原因大概率是复制活动的匹配逻辑或者列差异处理在重复运行时触发了非预期的更新判断，给你列几个最常见的排查方向：

• 目标表存在自动更新的列
  比如目标表有last_modified这类时间戳列，设置了默认值或者数据库触发器自动更新为当前时间。哪怕源数据完全没动，复制活动匹配键列后，会对比所有列的值——如果目标表的自动更新列和源表对应列（可能源表没有这个列，或者源表值是NULL）不一致，就会判定为「需要更新」，从而写入这条数据，导致Rows Written计数增加。
  👉 验证方式：去目标表查重复运行前后，那些「没改」的行是不是有某列（比如时间戳）被自动更新了。

• 列数据类型/精度的隐性差异
  源表和目标表的列虽然名字对应，但数据类型或精度不一致，比如源表是decimal(10,2)，目标表是decimal(10,3)；或者源是varchar(50)目标是nvarchar(50)。复制活动做值对比时，会因为这种隐性差异判定值不相等，进而执行更新操作。
  举个例子：源表的数值是10.0，目标表存成10.00，系统对比时会认为这两个值不同，触发更新。

• Upsert模式的默认逻辑特性
  你用的是Upsert（插入更新）模式对吧？有些ETL工具的Upsert逻辑，默认是只要键列匹配就执行更新，不会先做全列值对比——哪怕其他列值完全一样，也会覆盖目标行的对应列，这种情况下重复运行时每一条匹配的行都会被算作「写入」，所以Rows Written会等于源数据行数，而不是0。
  👉 解决方法：如果工具支持，开启「仅在值变化时更新」的选项，确保只有当源和目标列值确实不同时才执行更新。

• 源数据的隐性变化
  有时候看起来源数据没改，但其实存在隐性差异：比如源表某列是NULL，目标表对应列是默认值；或者源字符串列有不可见字符（空格、换行符），肉眼看不到但系统对比时会判定为不同。
  👉 验证方式：把源数据和目标数据导出到CSV，用对比工具逐行逐列检查，找出那些隐性差异。

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