update无where会全表更新并引发表级锁；read committed仍存在逻辑层丢失更新；for update需命中主键或唯一索引，否则退化为范围锁；事务崩溃需幂等设计；行级锁不能替代业务逻辑防重。
UPDATE时没加WHERE条件导致全表更新
这是最常见也最危险的丢失更新诱因：本想只改某一行，却因漏写WHERE条件，把整张表都锁住、改掉。MySQL在事务中执行UPDATE时，若无索引支持的WHERE，会升级为表级锁（尤其在READ COMMITTED或更低隔离级别下），其他事务被迫等待，甚至超时失败。
实操建议：
- 所有
UPDATE语句上线前必须检查WHERE是否存在，且字段有可用索引（用EXPLAIN确认是否走了索引） - 开发环境开启
sql_safe_updates=1，强制要求UPDATE/DELETE带WHERE或LIMIT - 避免用
SELECT ... FOR UPDATE后手动拼UPDATE——容易漏条件；优先用原子UPDATE ... WHERE id = ? AND version = ?做乐观锁
READ COMMITTED隔离级别下仍出现丢失更新
很多人以为设成READ COMMITTED就安全了，其实不然。该级别只保证不读脏数据，但两个事务仍可能先后读到同一行旧值，各自计算后写回，后写者覆盖前者（即“读-改-写”竞态）。这不是锁失效，而是逻辑层没防住。
实操建议：
- 对关键业务字段（如库存、余额）必须显式加锁：
SELECT * FROM account WHERE id = 123 FOR UPDATE，且该语句需在同一个事务内紧接后续UPDATE - 避免在事务里做耗时操作（如调外部API、复杂计算），否则
FOR UPDATE持有时间过长，拖慢并发 - 确认存储引擎是
InnoDB——MyISAM不支持行锁，FOR UPDATE无效
WHERE条件用了非主键/非唯一索引字段
比如用status = 'pending'加FOR UPDATE，而status只有普通索引，MySQL会锁住所有匹配的索引记录+间隙（next-key lock），范围可能远超预期，甚至锁住不该动的行，引发死锁或阻塞。
实操建议：
- 行级锁生效的前提是
WHERE能命中**唯一索引或主键**；否则退化为范围锁，行为难预测 - 用
SELECT ... FOR UPDATE前先查执行计划：EXPLAIN SELECT * FROM order WHERE user_id = 456，确认type是const或eq_ref - 如果业务确实要按状态批量处理，考虑加中间状态字段（如
lock_version）配合UPDATE ... WHERE id IN (?) AND lock_version = ?做CAS更新
事务提交前崩溃导致锁未释放
MySQL服务异常重启或连接断开时，未提交事务持有的FOR UPDATE锁会被自动释放，但应用层若没做幂等或重试判断，可能误认为操作失败而重复提交，造成二次更新。
实操建议：
- 应用层必须实现事务幂等：给每个业务操作生成唯一
trace_id，写入日志或单独幂等表，重试前先查是否已成功 - 不要依赖
autocommit=0手动管理事务——容易忘记COMMIT或ROLLBACK；用框架的声明式事务（如Spring@Transactional）更稳妥 - 监控
INFORMATION_SCHEMA.INNODB_TRX表，定期告警长时间未提交的事务
行级锁不是银弹，它只解决“同时改同一行”的物理冲突；真正的丢失更新，往往藏在业务逻辑和事务边界模糊的地方——比如两次查询之间插入了第三方修改，或者应用层缓存没及时失效。
