insert ... on duplicate key update 更安全因其为原子操作，避免“查+改”并发竞态；需有唯一约束，慎用col=col+1，推荐values(col)；replace into实为删+插，易致id跳变、外键误删、触发器错序。
INSERT ... ON DUPLICATE KEY UPDATE 为什么比先查再改更安全
因为“查 + 改”在并发下天然存在竞态：两个请求同时查不到记录，都执行 INSERT，触发唯一键冲突或主键重复错误。INSERT ... ON DUPLICATE KEY UPDATE 是原子操作，MySQL 在一行内完成匹配、插入或更新，避免中间状态暴露。
实操建议：
- 必须确保表上有
UNIQUE约束或PRIMARY KEY，否则ON DUPLICATE KEY UPDATE不生效 - 更新字段不要写成
col = col + 1这类表达式——它会在每次冲突时执行，但若多个并发同时触发，可能意外叠加多次（比如本该+1，结果+2） - 想让更新只发生在真正插入失败时？用
VALUES(col)函数区分来源：UPDATE col = VALUES(col)表示“用 INSERT 那一列的值覆盖”，而不是无条件加一
REPLACE INTO 的隐藏代价：它不是“UPSERT”，而是删+插
REPLACE INTO 看似简单，实际会先尝试 DELETE 匹配行（如果有），再 INSERT 新行。这带来三个现实问题：自增 ID 跳变、外键级联删除风险、触发器被触发两次。
常见错误现象：
- 表里自增主键从 100 突然跳到 105，查日志发现是
REPLACE INTO导致旧记录被删又重插 - 关联了
ON DELETE CASCADE的子表数据意外丢失 - 业务逻辑依赖 INSERT 触发器，但
REPLACE INTO先触发 DELETE 再触发 INSERT，顺序错乱
除非明确需要“强制覆盖并重置关联状态”，否则优先用 INSERT ... ON DUPLICATE KEY UPDATE。
事务中批量 upsert 性能卡在哪
单条 INSERT ... ON DUPLICATE KEY UPDATE 没问题，但拼成 500 行一起执行时，慢往往不是 SQL 本身，而是锁粒度和日志刷盘。
关键点：
- MySQL 8.0+ 对批量 upsert 做了优化，但前提是所有语句共用同一组唯一索引字段；混用不同唯一键会导致锁范围扩大
- 每条语句都会产生 binlog，大事务让主从延迟飙升——考虑拆成 100 行/批，用
BEGIN/COMMIT包裹 - 如果只是更新非索引字段，且允许“最终一致”，可关掉
innodb_flush_log_at_trx_commit=2（仅限从库或非核心业务）
PostgreSQL 怎么做等效 upsert
PostgreSQL 没有 ON DUPLICATE KEY UPDATE，对应的是 INSERT ... ON CONFLICT DO UPDATE，语法更显式，但也更容易写错。
容易踩的坑：
- 必须明确写出冲突目标：
ON CONFLICT (user_id)或ON CONFLICT ON CONSTRAINT users_pkey，漏写就报错ON CONFLICT requires a conflict specification -
EXCLUDED是个伪表名，代表本次想插入但被拦截的那行数据，更新时要写SET name = EXCLUDED.name，不能直接写name = name - 如果冲突列是联合唯一索引（如
(tenant_id, code)），ON CONFLICT必须完整列出字段，不能只写其中一个
复杂点在于：MySQL 的 ON DUPLICATE KEY UPDATE 自动识别所有唯一约束，而 PostgreSQL 要你亲手指定——漏一个，就变成静默失败或主键冲突报错。
