解决SQL事务冲突需依场景选锁：乐观锁（版本号/时间戳）适合读多写少，悲观锁（FOR UPDATE）适合强一致、写频繁场景；误用将致性能下降、死锁或脏数据。
解决SQL事务冲突，核心是控制并发访问下的数据一致性。乐观锁适合读多写少、冲突概率低的场景；悲观锁适合写频繁、需要强一致性的业务。选错锁机制，轻则性能下降，重则死锁或脏数据。
乐观锁：用版本号或时间戳避免强制等待
乐观锁不加锁，而是在更新时校验数据是否被其他事务修改过。典型做法是在表中增加 version（整型）或 updated_at（时间戳）字段。
- 查询时读取当前 version 值，例如：SELECT id, name, version FROM product WHERE id = 100;
- 更新时带上 version 条件：UPDATE product SET name = 'NewName', version = version + 1 WHERE id = 100 AND version = 5;
- 若影响行数为 0，说明 version 已变，发生冲突，应用层需重试或提示用户
- 注意：version 字段必须在每次更新时自增，且不能被业务逻辑绕过
悲观锁：数据库层面显式加锁，确保独占访问
悲观锁由数据库直接控制资源访问，适合短事务、高竞争场景，但容易引发锁等待甚至死锁。
- 查询即加锁：SELECT * FROM account WHERE id = 200 FOR UPDATE;（InnoDB 行级锁，事务提交后释放）
- 配合事务使用，避免锁范围过大：BEGIN; SELECT balance FROM account WHERE id = 200 FOR UPDATE; UPDATE account SET balance = balance - 100 WHERE id = 200; COMMIT;
- 慎用 SELECT ... LOCK IN SHARE MODE（共享锁），它允许其他事务读，但阻塞写，适用于读后再校验再写的流程
- 避免在长事务或应用层复杂处理中持有悲观锁，否则会拖慢整体并发能力
怎么选？看业务特征和数据库能力
没有银弹，关键看冲突频率、事务耗时、系统吞吐要求。
- 电商库存扣减：初期可用乐观锁（version），超卖风险可控；大促期间若冲突飙升，可切为悲观锁 + 缓存预减，再落库
- 银行转账：金额敏感、一致性要求极高，推荐悲观锁，配合唯一索引和小事务范围，降低锁粒度
- 用户资料编辑：通常单人操作，乐观锁足够；如支持协同编辑，则需更细粒度（如字段级版本或 OT 算法）
- 注意 MySQL 的隔离级别影响：READ COMMITTED 下 FOR UPDATE 只锁命中行；REPEATABLE READ 下可能触发间隙锁，需结合 WHERE 条件分析
进阶建议：组合用 + 监控兜底
真实系统往往混合使用，并辅以可观测手段提前发现问题。
- 对关键更新接口，统一封装乐观重试逻辑（最多 3 次，带指数退避）
- 在事务开始前用 SELECT ... FOR UPDATE NOWAIT 尝试加锁，捕获 LockWaitTimeoutException 快速失败，避免线程长时间挂起
- 监控 InnoDB 的 innodb_row_lock_waits 和 innodb_row_lock_time_avg，持续偏高说明锁竞争严重，需优化 SQL 或拆分热点行
- 考虑用分布式锁（如 Redis + Lua）协调跨库/跨服务操作，但仅用于无法用数据库锁覆盖的边界场景
