PostgreSQL 中真正幂等的 INSERT ... ON CONFLICT 必须精准匹配业务唯一性约束，即 ON CONFLICT 后明确指定已建 UNIQUE 索引的字段组合（如 (user_id, order_date)），并配合 DO NOTHING 或 DO UPDATE SET ... 使用 EXCLUDED 伪表，否则会报错或失效。
INSERT ... ON CONFLICT 在 PostgreSQL 中怎么写才真正幂等
PostgreSQL 的 INSERT ... ON CONFLICT 是实现幂等插入最直接的方式，但它不是“写了就安全”——关键在 ON CONFLICT 后指定的冲突目标是否精准匹配业务唯一性约束。
常见错误是只依赖主键（比如 id），但业务上真正需要防重的是组合字段（如 (user_id, order_date)）。若表上没建对应唯一索引，ON CONFLICT 会直接报错：there is no unique or exclusion constraint matching the ON CONFLICT specification。
实操建议：
- 先确认唯一性由哪个约束保障：用
\d table_name查看索引，确保你要依赖的字段组合上有UNIQUE索引（不是普通索引） - 显式写出冲突目标，不要只写
ON CONFLICT DO NOTHING——推荐写成ON CONFLICT (user_id, order_date) DO NOTHING，语义清晰且避免误触发 - 若需更新已有记录（如刷新
updated_at），用DO UPDATE SET updated_at = NOW()，但注意EXCLUDED伪表只能访问本次 INSERT 的值，不能引用原行其他字段做条件判断
REPLACE INTO 在 MySQL 中为什么常踩坑
MySQL 的 REPLACE INTO 看似简单，但它本质是「删 + 插」：先按主键或唯一键 DELETE 匹配行，再 INSERT 新行。这会导致几个隐性问题：
常见错误现象包括：自增 ID 意外跳变、触发器被调用两次（DELETE + INSERT 各一次）、外键级联操作被意外触发、时间戳字段被重置（即使你没在 VALUES 中提供）。
实操建议：
- 除非明确需要「覆盖式更新」且能接受上述副作用，否则优先改用
INSERT ... ON DUPLICATE KEY UPDATE -
ON DUPLICATE KEY UPDATE只在冲突时执行 UPDATE，不删除原行，ID 不变，触发器只触发一次 - UPDATE 子句中可用
VALUES(column_name)引用本次 INSERT 中该列的值，例如：last_seen = VALUES(last_seen) - 避免在 UPDATE 中写
created_at = NOW()—— 这会把原本有意义的创建时间覆盖掉
SQL Server 的 MERGE 语句怎么避免重复插入和死锁
SQL Server 的 MERGE 是功能最全的幂等插入方案，但也是最容易出错的。它要求必须有明确的 WHEN MATCHED 和 WHEN NOT MATCHED 分支，漏写任一分支会报语法错误。
更隐蔽的问题是并发场景下的死锁风险：多个 MERGE 同时扫描同一范围的索引页，又因内部加锁顺序复杂，极易形成循环等待。
实操建议：
- 始终为
MERGE的USING子句提供确定性小结果集，避免USING (SELECT * FROM huge_table)这类写法 - 确保
ON条件中的字段有高效索引，且类型严格匹配（比如INT对比VARCHAR会隐式转换，导致索引失效） - 如果只想要「存在即忽略」，
WHEN MATCHED THEN UPDATE SET @dummy = 0是合法占位写法，但别真去更新业务字段 - 生产环境高并发插入时，考虑加
WITH (HOLDLOCK)提示（等价于SERIALIZABLE），防止幻读引发的重复插入，但会降低吞吐
跨数据库通用方案：先 SELECT 再 INSERT/UPDATE 为什么通常不推荐
用 SELECT COUNT(*) WHERE ... 判断是否存在，再决定 INSERT 或 UPDATE，逻辑直观，但几乎总是错的——这不是幂等，是竞态条件温床。
典型错误现象：两个并发请求同时查到“不存在”，接着都执行 INSERT，违反唯一约束，抛出类似 duplicate key value violates unique constraint 的错误。
实操建议：
- 除非数据库完全不支持原生幂等语法（极少见），否则不要手写 SELECT+INSERT 两步逻辑
- 如果必须用（比如某些嵌入式数据库），至少把两步包在事务里，并设为
SERIALIZABLE隔离级别——但性能代价极大，且不是所有数据库默认支持 - 更现实的做法是：捕获唯一约束冲突异常，在应用层重试或降级处理，而不是在 SQL 层规避
真正难的不是写对一句 SQL，而是确认那条唯一约束本身是否覆盖了你的业务语义边界。比如「用户当天只能提交一次订单」，约束必须落在 (user_id, DATE(order_time)) 上，而不是粗略地用 order_no 或主键。漏掉这点，再漂亮的 ON CONFLICT 也白搭。
