MySQL的INSERT ... ON DUPLICATE KEY UPDATE依赖PRIMARY KEY或UNIQUE索引触发冲突处理，原子执行无竞态；若缺失对应唯一约束，则不生效或报错，且更新部分需谨慎处理NULL值与自增ID行为。
MySQL用 INSERT ... ON DUPLICATE KEY UPDATE 最直接
只要表里有 PRIMARY KEY 或 UNIQUE 约束，就能靠这条语句一步到位。它不是先查再判再插/更，而是由 MySQL 引擎内部原子执行，不存在竞态问题。
常见错误是没建唯一索引——比如想按 user_id 去重更新，但表里只有普通索引或没索引，那 ON DUPLICATE KEY UPDATE 根本不触发，会直接报错或插入重复行。
- 必须确保冲突字段（如
email、order_no）上有UNIQUE或主键约束 - 更新部分不能引用未在
VALUES()中显式提供的值，比如UPDATE name = VALUES(name)合法，但UPDATE updated_at = NOW()也合法，而UPDATE score = score + 1虽然能用，但要注意初始NULL值导致结果为NULL - 如果想让自增 ID 在冲突时不变化，就别在
INSERT里显式指定它；否则可能意外覆盖
INSERT INTO users (id, name, email) VALUES (123, 'Alice', 'a@b.com') ON DUPLICATE KEY UPDATE name = VALUES(name), email = VALUES(email);
PostgreSQL 用 INSERT ... ON CONFLICT DO UPDATE
语法更明确，必须写清冲突目标（比如 ON CONFLICT (email)），不像 MySQL 隐式依赖索引定义。这也是它更安全的地方：意图清晰，不会因索引变更而行为突变。
容易踩的坑是漏写 WHERE 条件导致误更新。比如只想更新非删除状态的记录，但忘记加 WHERE excluded.is_deleted = false，就会把已软删的行又“复活”。
-
excluded是个虚拟表，代表本次想插入但被拒绝的那行数据，所有字段都可通过excluded.xxx引用 - 冲突目标必须和某个
UNIQUE索引完全匹配，不能只写部分列（除非该索引本身就是联合唯一且你指定了全部列） - 如果表有多个唯一约束，而你只想对其中某一个做 upsert，就必须显式写出那个约束的列组合
INSERT INTO users (id, name, email) VALUES (123, 'Alice', 'a@b.com') ON CONFLICT (email) DO UPDATE SET name = EXCLUDED.name, updated_at = NOW();
SQL Server 的 MERGE 语句逻辑强但易出错
MERGE 功能最全，支持 WHEN MATCHED、WHEN NOT MATCHED、甚至 WHEN NOT MATCHED BY SOURCE，但也是最容易写错的——稍不留神就多更新、少插入，或者触发两次触发器。
典型问题是没加 AND 条件过滤匹配后的操作范围。例如想只更新未归档的记录，但只写了 WHEN MATCHED THEN UPDATE，没跟 AND target.archived = 0，结果把归档行也改了。
- 必须用
;结尾，否则在某些客户端里会报语法错误 -
USING子句里的源数据不能是带聚合或窗口函数的子查询（除非包装成 CTE） - 每个
WHEN分支最多只能有一个INSERT/UPDATE/DELETE，不能合并写
MERGE users AS target USING (VALUES (123, 'Alice', 'a@b.com')) AS source (id, name, email) ON target.email = source.email WHEN MATCHED THEN UPDATE SET name = source.name, updated_at = GETDATE() WHEN NOT MATCHED THEN INSERT (id, name, email) VALUES (source.id, source.name, source.email);
没有原生 UPSERT 的数据库（如 SQLite）得靠事务兜底
SQLite 5.0+ 其实已支持 INSERT OR REPLACE 和 INSERT OR IGNORE 组合，但前者会删再插，丢失自增 ID 和关联外键行为；后者只能防插入，不能更新。真要严格 upsert，还是得手动事务 + SELECT 判存 + INSERT/UPDATE 二选一。
这里的关键不是“怎么写”，而是“怎么防并发”。裸写 SELECT → IF → INSERT/UPDATE 在高并发下必然丢数据，必须加 BEGIN IMMEDIATE 或 BEGIN EXCLUSIVE，否则两个连接同时查到“不存在”，然后都去 INSERT，就冲突了。
- SQLite 的
REPLACE本质是DELETE + INSERT，如果行被其他表外键引用且设了ON DELETE CASCADE，会意外级联删数据 - 即使用了事务，也要注意锁粒度：
BEGIN IMMEDIATE只保证当前连接写时不被别的连接中断，但不阻止别人读，也不阻止别人对其他行写 - 如果业务允许“最后写入生效”，且冲突概率低，用
INSERT OR IGNORE+UPDATE（无视影响行数）反而更轻量
CREATE TABLE 语句里有没有真正生效的 UNIQUE 约束——没它，所有 upsert 语法都只是幻觉。 
