MySQL与Java如何避免并发数据覆盖

本文介绍在高并发场景下防止 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）才能勉强保证，但会显著降低并发吞吐；
• 代码冗余、易出错，且将数据一致性责任错误地交给了应用层。

? 补充建议：

• 对 place 字段建立唯一索引（如 UNIQUE(place)），可进一步防止重复插入引发的逻辑混乱；
• 若业务需记录抢占时间，可在 UPDATE 中一并设置 updated_at = NOW()；
• 高并发场景下，可结合乐观锁（如 version 字段）或分布式锁（如 Redis Lock）作为进阶防护，但本例中纯 SQL 条件更新已足够健壮。

综上，“SQL 条件更新 + 影响行数校验”是兼顾安全性、性能与可维护性的工业级标准做法，被 Spring JDBC、MyBatis 及主流 ORM 框架广泛采用。