通过try-catch判断数据库唯一键字段是否重复
在 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 并不是普通返回，它会触发：
创建异常对象（有可能包含堆栈快照 stack trace）。
异常从当前方法抛出，逐层回溯，直到找到匹配的 catch。
如果有 stack trace 打印，还会涉及额外的字符串拼接、I/O。
所以 throw 本身在 JVM 层面就比 if 要重很多。
2. 数据库层面
当 MySQL 插入违反唯一约束时，它并不是“返回 false”，而是：
先检测唯一索引冲突。
如果冲突，则构造错误码（1062）、错误信息（Duplicate entry …）。
通过驱动（JDBC）抛到 Java。
这意味着你触发了数据库错误路径，数据库和 JDBC 驱动要多做一些额外的处理。
3. 结合起来的理解
所以我说的“异常走的是数据库错误路径，开销比普通逻辑分支稍高”，意思是：
如果你在业务逻辑中 频繁依赖抛异常来做流程控制（比如大量数据都重复，几乎每次插入都报 Duplicate），那开销会比较大：
JVM 异常开销高于普通分支。
数据库错误处理开销高于正常 SQL 执行。
但如果你的场景是 大部分数据不会重复，偶尔才会碰到 DuplicateKeyException，那完全可以用 try-catch，因为正常路径走的还是普通 SQL 成功返回，异常的开销只在极少数情况下才体现。