MySQL丢失更新本质是并发事务覆盖导致数据丢失，需通过SELECT ... FOR UPDATE加排他锁、版本号乐观锁或调整隔离级别等方案解决，关键要确保事务完整性和锁的正确使用。
MySQL 中的丢失更新问题，本质是多个事务并发修改同一行数据时，后提交的事务覆盖了先提交事务的修改，导致部分更新“丢失”。要避免这个问题，核心是通过合适的隔离级别、锁机制或应用层控制来保证数据一致性。
使用更高的事务隔离级别
MySQL 默认隔离级别是 REPEATABLE READ，但它不能完全防止丢失更新（尤其在非唯一条件更新或无主键场景下）。升级到 READ COMMITTED 配合行级锁可改善，但最稳妥的是在关键业务中显式使用 SELECT ... FOR UPDATE 来加写锁。
- 在 UPDATE 前，先用
SELECT id, value FROM t WHERE id = 1 FOR UPDATE;锁定目标行 - 该语句会在满足条件的行上加排他锁（InnoDB），其他事务无法同时修改或再次加锁
- 确保整个操作在同一个事务内完成，避免锁过早释放
基于版本号（optimistic locking）控制
适用于读多写少、冲突概率低的场景。在表中增加 version 字段，每次更新都校验版本是否一致。
- 查询时带上 version：
SELECT id, value, version FROM t WHERE id = 1; - 更新时判断版本未变：
UPDATE t SET value = ?, version = version + 1 WHERE id = ? AND version = ?; - 检查
ROW_COUNT()是否为 1，为 0 表示已被其他事务更新，需重试或提示用户
使用 SELECT ... FOR UPDATE + 显式事务
这是 InnoDB 下最常用、最直接的悲观锁方案，适合高竞争写场景。
- 务必开启事务：
BEGIN;或START TRANSACTION; - 锁定要更新的记录：
SELECT * FROM account WHERE user_id = 100 FOR UPDATE; - 执行业务逻辑（如余额计算），再执行
UPDATE - 最后
COMMIT;或ROLLBACK;—— 不提交事务会导致锁长期持有
避免隐式提交与长事务
丢失更新有时并非逻辑问题，而是因事务意外提前结束或锁被释放。
- 禁用自动提交：
SET autocommit = 0;，否则单条 UPDATE 会立即提交并释放锁 - 减少事务内耗时操作（如远程调用、大循环），防止锁持有时间过长引发死锁或超时
- 注意 MySQL 的
innodb_lock_wait_timeout设置，默认 50 秒，超时会报错而非静默失败
