最可靠方案是单条UPDATE语句配合WHERE条件校验，因其原子性可天然拦截无效更新；必须确保索引存在，否则并发覆盖或锁表风险不可避免。
直接结论：不要在应用层做“先SELECT再UPDATE”，必须把判断和修改压进单条SQL，或用SELECT ... FOR UPDATE配合显式事务——否则并发覆盖不可避免。
为什么单条UPDATE语句 + WHERE条件校验最可靠
因为MySQL的UPDATE本身是原子操作，只要WHERE子句包含业务约束（比如余额、库存、状态），就能天然拦截无效更新。
- ✅ 正确写法：
UPDATE accounts SET balance = balance - 50 WHERE id = 123 AND balance >= 50；执行后检查ROW_COUNT()是否为1，为0说明条件不满足（如余额不足），不是失败而是业务拒绝 - ❌ 错误写法：
UPDATE accounts SET balance = 150 WHERE id = 123；不管当前值是多少都硬覆盖，两个并发事务都会成功，后提交者必然覆盖前者的计算结果 - ⚠️ 索引必须存在：
id字段要有主键或唯一索引，否则WHERE扫描可能触发表锁；范围条件（如balance >= 50）也建议给balance加索引，避免全表扫描 - ? 在
READ COMMITTED和REPEATABLE READ下都安全，但READ UNCOMMITTED不推荐——它允许脏读，可能让WHERE条件基于未提交的中间值判断
SELECT ... FOR UPDATE必须满足三个前提才有效
它不是加了就万事大吉的“银弹”，漏掉任一条件就会退化为无锁状态或锁表。
- ✅ 必须显式开启事务：
BEGIN或START TRANSACTION，不能依赖autocommit；否则SELECT ... FOR UPDATE执行完立刻释放锁 - ✅ WHERE条件必须走索引：用
EXPLAIN SELECT ... FOR UPDATE确认type是const/ref，且key列显示实际索引名；WHERE status = 'pending'没索引？那就锁整张表 - ✅ 锁的是“查到的行”，不是“逻辑状态”：比如查到
stock = 5并加锁，不代表后续UPDATE时仍为5——别人可能在你锁住后、UPDATE前已扣减；所以必须在事务内立刻判断并UPDATE，中间不能穿插HTTP调用、sleep等长耗时操作 - ⚠️ 注意死锁风险：多个事务按不同顺序加锁（如事务A先锁id=123再锁id=456，事务B反之），极易触发死锁；建议所有业务统一按主键升序加锁
INSERT ON DUPLICATE KEY UPDATE的坑比想象中多
它只解决“查再插”类竞态，对纯UPDATE场景无效，且UPDATE子句写法不当会引入新问题。
- ✅ 安全场景：有唯一索引（主键或UNIQUE约束），且业务逻辑可归结为“存在则更新，不存在则插入”；例如发券：
INSERT INTO coupon (user_id, code) VALUES (123, 'ABC') ON DUPLICATE KEY UPDATE used = 1, updated_at = NOW() - ❌ 危险写法：
counter = counter + 1——在REPEATABLE READ下，counter读取的是语句开始时的快照值，两个并发事务都读到100，都算出101，最终变成101而非102 - ⚠️ 不触发的场景：唯一索引冲突才走UPDATE分支；如果靠
WHERE status = 'draft'这类非唯一条件判断，它完全不生效，得换INSERT ... SELECT ... WHERE NOT EXISTS - ? 替代方案：
INSERT INTO t SELECT ... FROM DUAL WHERE NOT EXISTS (SELECT 1 FROM t WHERE ...)，在REPEATABLE READ下自带间隙锁，能防幻读干扰
乐观锁（version字段）不是数据库自动功能
它依赖应用层完整控制，数据库不会帮你校验version，也不会拦截漏传version的UPDATE。
- ✅ 正确姿势：UPDATE语句必须显式带
WHERE version = ?，且应用层在UPDATE后检查ROW_COUNT()；为0则重试（读最新version再试）或抛异常 - ❌ 常见错误：在MyBatis里只写
UPDATE t SET name = #{name} WHERE id = #{id}，漏掉AND version = #{version}；或者用触发器自增version，但没在WHERE里比对 - ⚠️ 注意并发重试成本：高冲突率下反复读-改-写+重试，可能比悲观锁更耗资源；适合读多写少、冲突概率低的场景（如用户资料页）
- ? 版本字段类型建议用
BIGINT或TIMESTAMP，避免INT溢出；更新时用version = version + 1，别用NOW()——时钟漂移会导致版本乱序
真正容易被忽略的是存储引擎和索引设计：没有InnoDB、没有主键/唯一索引，上面所有方案都会失效。锁、间隙锁、ON DUPLICATE KEY UPDATE、WHERE NOT EXISTS，全都依赖索引结构才能落地。别在没建好地基时急着盖楼。
