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 秒，超时会报错而非静默失败
