17370845950

SQL唯一约束冲突本质是业务逻辑未兜住的数据重复写入，解决需分实时避冲突与并发优雅处理两层：写入前校验须配合事务和SELECT...FOR UPDATE锁防竞态；更推荐捕获唯一索引异常后幂等更新、静默忽略或业务回退；治本之策是在前端、网关（Redis分布式锁）、MQ消费端（布隆过滤器）等链路早期去重；批量导入应先比对再处理，避免IGNORE掩盖问题。

SQL唯一约束冲突本质是数据重复写入，不是数据库出错，而是业务逻辑没兜住。解决思路分两层：一是实时写入时避免冲突，二是历史或并发场景下优雅处理重复。

写入前主动校验（适合低并发、强一致性场景）

在INSERT前用SELECT检查是否存在相同值，但要注意这会引入竞态条件——两次检查之间可能已被其他事务插入。所以必须配合事务和锁：

• 用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语义
• 记录每条失败的原始数据+错误原因，用于后续审计和规则优化