本文介绍在高并发场景下防止 mysql 数据被意外覆盖的两种常见策略，重点推荐基于 sql 原子条件更新的方案，并说明如何通过检测影响行数实现可靠的数据一致性保障。
在多用户同时操作同一张表（如抢座、抢票、库存扣减）的业务中，若不加控制，极易发生“后写覆盖前写”的并发问题。例如：两个用户几乎同时尝试预订同一个座位（place = 'A1'），若仅用 SELECT + UPDATE 两步操作，极可能因竞态条件导致两人均读到 user_user_id IS NULL，最终都成功写入，造成数据逻辑错误。
✅ 推荐方案：单条原子化 SQL 条件更新（Option 1）
使用带严格 WHERE 条件的 UPDATE 语句，确保更新操作本身具备排他性和原子性：
UPDATE ticket SET user_user_id = ? WHERE place = ? AND user_user_id IS NULL;
该语句天然具备以下优势：
- 原子性：MySQL 在执行时一次性完成条件判断与更新，无需外部锁或事务隔离级别强依赖；
- 高效性：避免了额外的 SELECT 查询，减少网络往返和数据库负载；
- 简洁性：业务逻辑下沉至数据层，Service 层更轻量、更易测试。
⚠️ 关键实践：必须校验影响行数
仅执行 SQL 不够——需在 Java DAO 层检查 executeUpdate() 返回值：
public void assignTicket(String place, Long userId) throws DAOException {
String sql = "UPDATE ticket SET user_user_id = ? WHERE place = ? AND user_user_id IS NULL";
int rowsAffected = jdbcTemplate.update(sql, userId, place);
if (rowsAffected == 0) {
throw new DAOException("Place '" + place + "' has already been taken");
}
}若返回 0，说明该座位已被他人抢先占用（或根本不存在），此时抛出明确异常，由上层处理重试、提示或降级逻辑。
❌ 不推荐方案：应用层先查后更（Option 2）
虽然逻辑直观，但存在固有缺陷：
- 即使加 @Transactional(isolation = REPEATABLE_READ)，也无法完全避免两次查询间的窗口期（尤其在长事务或高延迟场景）；
- 需要额外加锁（如 SELECT ... FOR UPDATE）才能勉强保证，但会显著降低并发吞吐；
- 代码冗余、易出错，且将数据一致性责任错误地交给了应用层。
? 补充建议：
立即学习“Java免费学习笔记（深入）”；
- 对 place 字段建立唯一索引（如 UNIQUE(place)），可进一步防止重复插入引发的逻辑混乱；
- 若业务需记录抢占时间，可在 UPDATE 中一并设置 updated_at = NOW()；
- 高并发场景下，可结合乐观锁（如 version 字段）或分布式锁（如 Redis Lock）作为进阶防护，但本例中纯 SQL 条件更新已足够健壮。
综上，“SQL 条件更新 + 影响行数校验”是兼顾安全性、性能与可维护性的工业级标准做法，被 Spring JDBC、MyBatis 及主流 ORM 框架广泛采用。
