UPDATE语句本身是原子的，但业务原子性需靠WHERE条件校验和影响行数检查来保障；正确做法是将约束写入WHERE子句并检查ROW_COUNT()，而非依赖SELECT+UPDATE或SELECT FOR UPDATE。
UPDATE 本身在单条语句层面就是原子的——它要么整行更新成功，要么失败（如违反约束、锁超时），不会出现“只改了一半字段”的情况。但业务常说的“原子性问题”，其实是指业务逻辑的原子性缺失：比如“扣库存”这个动作，常被拆成 SELECT + UPDATE 两步，中间留出竞态窗口。事务隔离级别对此作用有限，甚至可能误导你加错锁。
UPDATE ... WHERE 条件校验才是真原子
MySQL 的 UPDATE 支持在一条语句中完成“读判断 + 写修改”，只要把业务约束写进 WHERE 子句，就能堵死竞态窗口。
- 常见错误：先
SELECT stock FROM products WHERE id = 1001，再UPDATE products SET stock = stock - 1 WHERE id = 1001- 即使事务设为
REPEATABLE READ，两次查询之间仍有时间差，两个事务可能同时读到stock = 5，都执行减 1，最终变成 3 而非预期的 4
- 即使事务设为
- 正确写法：
UPDATE products SET stock = stock - 1 WHERE id = 1001 AND stock >= 1- 数据库引擎在执行时一次性读取当前值、判断条件、执行减法、写回新值，全程无外部干预
- 执行后必须检查影响行数：
@@ROWCOUNT（SQL Server）、ROW_COUNT()（MySQL）、pg_affected_rows()（PostgreSQL）为 0 表示条件不满足（已售罄或被抢）
UPDATE 的原子性不依赖隔离级别，而依赖你是否把校验逻辑“下沉到 SQL 层”。
SELECT FOR UPDATE 不是万能解药，反而容易拖垮系统
盲目用 SELECT FOR UPDATE 是并发场景下最常见也最危险的误操作。
- 它确实能锁住目标行，但：
- 锁持有时间从“执行完 UPDATE”延长到“整个事务 COMMIT”，若事务里还有其他耗时操作（如调用外部 API、复杂计算），锁就卡在那里
- 多个事务争同一行锁，可能触发死锁；InnoDB 会随机选一个作为牺牲者（
@@ERROR返回 -2），但应用层若没检查就直接忽略，数据就静默错了 - MySQL 的
SELECT FOR UPDATE在READ COMMITTED下只锁命中的行，在REPEATABLE READ下还可能锁间隙（Gap Lock），范围比你想象的大得多
- 更糟的是：如果连接异常断开，锁不会自动释放（尤其在未显式
COMMIT/ROLLBACK时），残留锁会阻塞后续所有请求
除非你明确需要在读之后、更新之前做跨表校验或复杂业务判断（比如查用户等级+查积分+查优惠券状态），否则别碰 SELECT FOR UPDATE。
事务隔离级别对 UPDATE 原子性几乎没直接影响
很多人以为把事务设成 SERIALIZABLE 就万事大吉，其实不然。
-
READ UNCOMMITTED/READ COMMITTED/REPEATABLE READ主要影响的是SELECT看到什么数据，而不是UPDATE是否原子 - 即使在
READ COMMITTED下，UPDATE ... WHERE stock >= 1依然能正确防止超卖，因为它读的是最新已提交值，且整个语句执行不可分割 -
SERIALIZABLE会让普通SELECT自动加上共享锁，反而增加锁冲突概率，吞吐量断崖下跌，却解决不了“先查后更”的根本问题
真正起作用的，永远是你写的 WHERE 条件是否覆盖了业务约束，以及你是否检查了返回的影响行数。
UPDATE 的原子性保障，核心不在事务怎么开、隔离级别怎么设，而在于你有没有把“判断逻辑”塞进 SQL 本身，并且每次执行后都看一眼 ROW_COUNT()。漏掉这一行检查，前面所有设计都白搭。
