SQL唯一约束冲突本质是业务逻辑未兜住的数据重复写入，解决需分实时避冲突与并发优雅处理两层：写入前校验须配合事务和SELECT...FOR UPDATE锁防竞态；更推荐捕获唯一索引异常后幂等更新、静默忽略或业务回退；治本之策是在前端、网关（Redis分布式锁）、MQ消费端（布隆过滤器）等链路早期去重；批量导入应先比对再处理，避免IGNORE掩盖问题。
SQL唯一约束冲突本质是数据重复写入，不是数据库出错，而是业务逻辑没兜住。解决思路分两层：一是实时写入时避免冲突，二是历史或并发场景下优雅处理重复。
写入前主动校验（适合低并发、强一致性场景）
在INSERT前用SELECT检查是否存在相同值，但要注意这会引入竞态条件——两次检查之间可能已被其他事务插入。所以必须配合事务和锁：
- 用red">SELECT ... FOR UPDATE锁定待检查的索引范围（需确保查询能命中唯一索引）
- 开启事务，检查→插入必须在同一事务内完成
- 注意：高并发下易导致锁等待甚至死锁，不建议作为主方案
写入时捕获异常并重试/降级（推荐主流做法）
直接执行INSERT，靠数据库唯一约束拦截重复，应用层捕获SQLSTATE '23000'或具体数据库错误码（如MySQL 1062、PostgreSQL 23505），再决定后续动作：
-
幂等更新：冲突时改用UPDATE，例如
INSERT ... ON DUPLICATE KEY UPDATE（MySQL）或INSERT ... ON CONFLICT DO UPDATE（PostgreSQL） - 静默忽略：确认重复可丢弃，返回成功（适合日志、埋点类场景）
- 业务回退+提示：如注册时用户名已存在，返回明确错误信息给前端
从业务源头做去重（治本之策）
数据库约束只是最后一道防线。真正稳定的去重要落在业务链路早期：
- 前端提交前查重（仅作友好提示，不可依赖）
- 网关或服务入口层用分布式锁（如Redis SETNX）对关键字段加锁，锁粒度尽量小（比如锁“手机号”而非“用户服务”）
- 消息队列消费端做本地缓存+布隆过滤器预判，再查DB，减少无效穿透
- 对生成型ID（如订单号），用含时间戳+机器码+序列的全局唯一ID，从源头规避冲突
批量导入时的特殊处理
大批量INSERT IGNORE或ON CONFLICT可能掩盖真实问题。建议：
- 先用临时表载入，通过LEFT JOIN比对找出重复记录，单独导出分析原因
- 对确定要覆盖的场景，用MERGE或UPSERT语句，明确区分INSERT/UPDATE语义
- 记录每条失败的原始数据+错误原因，用于后续审计和规则优化
