本文介绍在高并发场景下防止数据库记录被意外覆盖的两种主流方案，重点分析基于 sql 条件更新的原子性优势，并给出推荐实践：使用带行校验的 `update ... where` 语句，配合受影响行数判断实现线程安全的数据抢占。
在多用户同时操作同一张表（如座位预订系统中的 ticket 表）时，“最后写入获胜”（Last-Write-Wins）可能导致关键业务逻辑失效——例如两个用户几乎同时抢同一个座位，结果后提交者无声覆盖前者的成功预订。为确保数据一致性，必须在更新前验证目标记录的当前状态是否符合预期（如 user_user_id IS NULL），且该验证与更新操作需具备原子性。
✅ 推荐方案：SQL 层原子条件更新（首选）
直接在 SQL 中嵌入业务约束条件，利用数据库的 ACID 特性保证操作不可分割：
UPDATE ticket SET user_user_id = ? WHERE place = ? AND user_user_id IS NULL;
在 Java 服务层调用后，必须检查执行结果：
int updatedRows = jdbcTemplate.update(
"UPDATE ticket SET user_user_id = ? WHERE place = ? AND user_user_id IS NULL",
userId, place
);
if (updatedRows == 0) {
throw new BusinessException("座位 [" + place + "] 已被占用，无法预订");
}✅ 优势显著：
- 原子性保障：整个“读状态+写数据”由单条 SQL 完成，避免竞态窗口；
- 无额外查询开销：相比先 SELECT 再 UPDATE，减少一次数据库往返；
- 强一致性：依赖数据库锁机制（如行级 Next-Key Lock），天然规避并发冲突；
- 简洁可测：逻辑集中、边界清晰，单元测试易覆盖成功/失败分支。
⚠️ 不推荐方案：应用层先查后更（存在风险）
// ❌ 潜在问题：两次数据库交互间存在竞态窗口
Ticket ticket = ticketDAO.read(place); // 时间点 T1
if (ticket.getUser() == null) {
ticket.setUser(user);
ticke
tDAO.update(ticket); // 时间点 T2 → T1 到 T2 之间可能已被他人抢占
}
该方式虽逻辑直观，但因 SELECT 和 UPDATE 是两个独立事务操作，在高并发下极易出现「幻读」或「丢失更新」：用户 A 查询到空闲座位后，用户 B 在 A 执行 UPDATE 前抢先完成预订，A 仍会覆写成功，导致数据错误。
? 进阶建议（按需选用）
- 添加乐观锁字段：对复杂场景（如需校验多个字段状态），可在表中增加 version 列，使用 UPDATE ... SET ..., version = version + 1 WHERE version = ? 实现版本控制；
- 使用 SELECT ... FOR UPDATE：若需在事务内进行复杂业务判断（如库存扣减+日志生成），可显式加行锁，但需注意死锁风险与事务粒度；
- 幂等设计：对外暴露的接口应支持重复请求识别（如通过唯一业务 ID），避免网络重试引发重复占座。
✅ 总结
在“抢占式更新”类场景（如票务、库存、预约）中，将业务校验逻辑下沉至 SQL 的 WHERE 子句，并严格校验 UPDATE 返回的受影响行数，是兼顾安全性、性能与可维护性的工业级标准做法。它以最小侵入性 leverages 数据库原生能力，是 Spring JDBC、MyBatis 等主流框架中广泛采用的稳健模式。
