DBeaver中选Replace不是UPSERT，而是DELETE+INSERT；真正UPSERT需按数据库启用对应语法（如PostgreSQL勾选ON CONFLICT）；Replace失败常见于无主键、外键阻塞、Truncate优先或数据重复；格式错误会阻止upsert执行；验证需查日志或手动比对数据。
“Replace method” 选 Replace 就是 upsert 吗？
不是。DBeaver 的 Replace method 选项里选 Replace，**不等于数据库层面的 UPSERT（INSERT ... ON CONFLICT / MERGE）**。它只是 DBeaver 在加载过程中模拟的一种覆盖逻辑：遇到主键或唯一键冲突时，先 DELETE 原有行，再 INSERT 新行。这会产生两笔日志、可能触发两次触发器，且不支持部分字段更新（即不能只改几个列，而是整行替换）。
真正想实现“有则更新、无则插入”，得看目标数据库是否原生支持 UPSERT，并确认 DBeaver 是否启用了对应语法生成：
- PostgreSQL：需勾选
Use INSERT ... ON CONFLICT（在导入向导「加载设置」页底部，非默认开启） - MySQL：DBeaver 会自动用
INSERT ... ON DUPLICATE KEY UPDATE，但前提是目标表有明确的PRIMARY KEY或UNIQUE约束，且你没禁用该行为 - Oracle：仅当使用
MERGE INTO模式时才等效，需手动在高级设置中启用（路径：导入向导 → 「加载设置」→ 展开「Advanced」→ 勾选Use MERGE statement）
为什么勾选了 Replace 还报主键冲突错误？
因为 Replace method 的实际生效，依赖于底层数据库能否执行 DELETE + INSERT 流程。常见失败原因：
- 目标表没定义主键或唯一约束 → DBeaver 无法识别“哪一行算重复”，
Replace退化为普通INSERT，直接报错 - 外键约束存在且未禁用 →
DELETE阶段被外键阻止（比如子表还引用着这行），整个事务回滚 - 你勾选了
Truncate target table(s) before load→ 它优先级高于Replace method，会先清空全表，后续不再做冲突判断 - 源数据里有重复主键值（同一文件内多行 id=100）→ 即使表为空，第二行插入也会因主键已存在而失败
CSV 导入时想 upsert，但日期/数字格式总出错
格式问题会卡在类型转换阶段，导致 upsert 逻辑根本没机会执行。关键检查点：
- 在「列映射」步骤中，对目标列为
TIMESTAMP或DATE的字段，必须手动点击「Edit」设置匹配的输入格式，例如yyyy-MM-dd HH:mm:ss；否则 DBeaver 默认按yyyy-MM-dd解析，遇到"2026-11-05 14:30:00"就抛异常 - 数字字段含千分位（如
"1,234.56"）：DBeaver 不自动去除逗号，需提前清洗，或在「列映射」里对该列启用「Transform」→ 选择Remove all non-digit chars except dot and minus - 空字符串
""往NOT NULL列导：即使选了Replace，也属于约束违规，不是冲突，不会触发覆盖逻辑 —— 必须用NULL或补默认值
如何验证 upsert 真正生效了？
别只看“执行成功”提示。DBeaver 的 DataTransferState 会统计三类行数：inserted、updated（仅限真正 UPSERT 模式）、skipped。但这个统计在 UI 上不显眼，得靠日志：
打开 DBeaver 控制台（Window > Show View > Error Log），搜索关键词 rows inserted 或 rows updated。如果看到类似 123 rows inserted, 45 rows updated，说明启用了原生 UPSERT；若只有 168 rows inserted，那大概率走的是 DELETE+INSERT 路径，或者所有行都是新增的。
最保险的方式：导入前查一次主键值数量，导入后用 SELECT COUNT(*) FROM t WHERE id IN (...) 对比，再抽样 SELECT * FROM t WHERE id = ? 看字段是否被更新 —— 因为 DBeaver 的“update”统计有时会把 DELETE+INSERT 也记成 update，容易误判。
