通过try-catch判断数据库唯一键字段是否重复-CSDN博客

在 MyBatis + MySQL 项目里，完全可以通过 try-catch 捕获数据库抛出的唯一约束异常 来判断是否重复，从而避免提前多一次 SELECT 查询。

1、原理

MySQL 在插入数据时，如果违反唯一索引约束（Duplicate entry），会抛出 SQL 异常。
通过 MyBatis 调用时，这个异常会被包装成 Java 异常（比如 org.springframework.dao.DuplicateKeyException，如果你用了 Spring；或者原生的 java.sql.SQLIntegrityConstraintViolationException）。
你可以在代码里直接捕获并处理。

示例代码

假设用了spring+MyBaits：

try {
    myMapper.insert(clue);
} catch (DuplicateKeyException e) {
    // 这里捕获到 clue_id 唯一索引冲突
    log.warn("clue_id 已存在: {}", clue.getClueId());
    // 业务逻辑：例如更新已有数据，或者提示用户
}

如果没用 Spring，只是原生 MyBatis，可以捕获更底层的 SQL 异常：

try {
    myMapper.insert(clue);
} catch (SQLIntegrityConstraintViolationException e) {
    if (e.getErrorCode() == 1062) { // 1062 是 MySQL 的 Duplicate entry 错误码
        log.warn("clue_id 已存在: {}", clue.getClueId());
        // 业务处理
    } else {
        throw e; // 不是唯一约束异常就继续抛出
    }
}

✅ 优点

避免额外的 SELECT 查询，减少一次数据库交互。
并发场景下比先查再插入更安全（避免查询和插入之间的 race condition）。

⚠️ 缺点

异常走的是数据库错误路径，开销比普通逻辑分支稍高（但大多数业务场景下可以接受）。
如果异常抛出很频繁，可能会影响性能，最好在业务设计上减少重复的可能。

2、怎么理解“异常走的是数据库错误路径，开销比普通逻辑分支稍高”？

1. 普通逻辑分支 vs 异常机制

在 Java 里，正常的逻辑判断（比如 if 判断）和异常处理机制（try-catch）的开销是不一样的。

普通逻辑分支：JVM 在执行 if 判断时，基本就是一次条件判断+跳转，开销很小。
异常机制：Java 的 throw 并不是普通返回，它会触发：
1. 创建异常对象（有可能包含堆栈快照 stack trace）。
2. 异常从当前方法抛出，逐层回溯，直到找到匹配的 catch。
3. 如果有 stack trace 打印，还会涉及额外的字符串拼接、I/O。
所以 throw 本身在 JVM 层面就比 if 要重很多。

2. 数据库层面

当 MySQL 插入违反唯一约束时，它并不是“返回 false”，而是：

先检测唯一索引冲突。
如果冲突，则构造错误码（1062）、错误信息（Duplicate entry …）。
通过驱动（JDBC）抛到 Java。

这意味着你触发了数据库错误路径，数据库和 JDBC 驱动要多做一些额外的处理。

3. 结合起来的理解

所以我说的“异常走的是数据库错误路径，开销比普通逻辑分支稍高”，意思是：

如果你在业务逻辑中 频繁依赖抛异常来做流程控制（比如大量数据都重复，几乎每次插入都报 Duplicate），那开销会比较大：
- JVM 异常开销高于普通分支。
- 数据库错误处理开销高于正常 SQL 执行。
但如果你的场景是 大部分数据不会重复，偶尔才会碰到 DuplicateKeyException，那完全可以用 try-catch，因为正常路径走的还是普通 SQL 成功返回，异常的开销只在极少数情况下才体现。