数据库主键冲突属于不可重试的业务错误，但可在自定义ID碰撞、唯一键并发插入、乐观锁降级等可规避场景下设计带主键重生成、事务隔离和次数限制的自动重试机制。
数据库主键冲突（如 MySQL 的 1062 Duplicate entry、PostgreSQL 的 23505 错误）属于**不可重试的业务错误**，直接重试插入操作大概率再次失败。但若场景合理（例如：分布式 ID 生成偶发碰撞、乐观锁更新失败后需重生成主键再试、或幂等写入需降级为更新），可设计**有约束的自动重试机制**——关键在于区分“真冲突”和“可规避冲突”，并配合事务控制。
识别并过滤真正可重试的主键冲突
不是所有主键重复都该重试。必须先判断是否属于可规避场景：
- 自定义主键生成失败：比如用时间戳+随机数生成 ID，极小概率重复 → 可重试，且应重新生成新主键
- 并发插入同一业务唯一键（非主键）：如用户注册时用手机号作唯一索引，两个请求几乎同时提交 → 可重试，但需加分布式锁或先查后插（select for update）
- 乐观锁更新失败后转插入：版本号不匹配导致更新失败，业务允许降级为插入新记录 → 属于逻辑重试，非单纯主键重试
-
明确不可重试的情况：如手动指定主键为
1001且已存在，重试无意义；或违反业务规则（如重复下单）→ 应抛出业务异常，不进重试流程
手动重试：封装带主键再生的插入逻辑
避免简单 while + try-catch 循环重插同一数据。推荐封装为函数式重试工具，支持主键重生成：
- 传入一个
Supplier<T>用于每次重试时生成新主键对象（如新 UUID、新 Snowflake ID） - 捕获特定 SQL 异常码（如 MySQL 的
SQLState = "23000"且 message 含"Duplicate entry"） - 设置上限（建议 ≤ 3 次），第 n 次失败后抛出原始异常，不静默吞掉
- 每次重试前清空一级缓存（如 JPA 的
EntityManager.clear()），防止脏状态干扰
示例片段：
立即学习“Java免费学习笔记（深入）”；
（伪代码，基于 Spring Data JPA）public <T> T insertWithKeyRegen(Supplier<T> entitySupplier, int maxRetries) throws Exception {
for (int i = 0; i < maxRetries; i++) {
T entity = entitySupplier.get();
try {
return repository.save(entity);
} catch (DataIntegrityViolationException e) {
if (isDuplicateKeyException(e) && i < maxRetries - 1) {
continue; // 准备下一次重试
}
throw e;
}
}
throw new RuntimeException("Insert failed after " + maxRetries + " attempts");
}Spring Retry 配合事务与恢复逻辑
若使用 @Retryable，需特别注意两点：
-
必须在独立事务中执行：主键冲突会标记当前事务为 rollback-only，若重试在同一事务内，后续操作全部失效。应在
@Retryable方法上加@Transactional(propagation = Propagation.REQUIRES_NEW) - @Recover 方法要处理最终失败：比如记录冲突日志、发告警、或转为异步补偿任务（如写入死信表供人工核查），而不是再试一次插入
-
异常类型要显式声明：默认不重试受检异常，且
DataIntegrityViolationException是运行时异常，但需确认其是否被 Spring 的事务拦截器提前捕获。建议在@Retryable中明确 include：@Retryable(include = {DataIntegrityViolationException.class})
更健壮的替代方案：优先用数据库层解决
比起应用层重试，以下方式更可靠、更轻量：
- INSERT ... ON DUPLICATE KEY UPDATE（MySQL） 或 MERGE（PostgreSQL/Oracle）：一条语句完成“存在则更新，不存在则插入”，天然幂等
- 先 SELECT FOR UPDATE 再 INSERT：在事务中加行锁，确保检查与插入原子性（适合低并发、高确定性场景）
- 数据库唯一约束 + 应用层兜底提示：让数据库做最终校验，应用捕获异常后友好提示用户（如“该手机号已被注册”），而非隐藏重试
