SQL如何解决插入数据时违反唯一约束的问题

直接捕获唯一约束异常比预查更可靠，因预查存在竞态窗口、锁表风险及死锁隐患，而直接INSERT配合捕获1062错误码或ON DUPLICATE KEY UPDATE等机制可实现高效幂等写入。

sql如何解决插入数据时违反唯一约束的问题_分析处理策略

直接捕获唯一约束异常比预查更可靠

预查（先 SELECT 再 INSERT）看似直观，但天然存在竞态窗口：两次请求查完都没数据，却在插入前被对方抢先写入。哪怕加了事务，也得配合 SELECT ... FOR UPDATE，且必须命中唯一索引才能锁住对应行——否则可能锁表或锁不住。高并发下还容易引发锁等待甚至死锁。

更稳的做法是信任数据库的约束检查能力，直接执行 INSERT，在应用层捕获具体错误码：

MySQL：捕获错误号 1062 或 SQLSTATE '23000'
PostgreSQL：捕获 SQLSTATE '23505'
Dameng（达梦）：捕获异常信息含 Violate unique constraint
Oracle：捕获 ORA-00001，用 DUP_VAL_ON_INDEX 异常名处理

捕获后不硬抛错，而是走业务逻辑分支——这才是生产环境的主流做法。

MySQL 用 `ON DUPLICATE KEY UPDATE` 实现幂等写入

这是 MySQL 最常用、语义最清晰的冲突处理方式。它要求目标字段上有 PRIMARY KEY 或 UNIQUE 索引，触发条件是插入值与已有索引键冲突。

示例：

INSERT INTO tb_user (id_card, username) 
VALUES ('370000199901016666', '张三新名') 
ON DUPLICATE KEY UPDATE username = VALUES(username), updated_at = NOW();

注意点：

VALUES(column) 引用的是本次 INSERT 中该列的原始值，不是当前行旧值
不要滥用 REPLACE INTO：它本质是 DELETE + INSERT，会丢失自增 ID、触发 DELETE 钩子、破坏外键引用计数
INSERT IGNORE 仅静默跳过，无法更新，也不返回影响行数（mysql_affected_rows() 为 0），不利于判断是否真发生了冲突

PostgreSQL 必须用 `ON CONFLICT DO UPDATE` 而非 MERGE

PostgreSQL 不支持标准 SQL 的 MERGE，唯一合规的 UPSERT 方式是 ON CONFLICT。它的语法更显式，必须指定冲突目标（索引名或列名），避免误匹配。

示例（基于唯一索引 un_id_card）：

INSERT INTO tb_user (id_card, username) 
VALUES ('370000199901016666', '李四') 
ON CONFLICT ON CONSTRAINT un_id_card 
DO UPDATE SET username = EXCLUDED.username, updated_at = NOW();

关键细节：