sql并发更新冲突本质是多事务改同一行致业务异常，解决核心是控制并发行为而非避免并发，常用方案包括乐观锁、悲观锁、原子更新+条件判断及分布式锁兜底。
SQL 并发更新冲突本质是多个事务同时修改同一行数据，导致结果不符合业务预期。核心思路不是“避免并发”，而是“控制并发下的行为”——明确谁该赢、何时重试、怎么检测冲突。下面从常见场景出发，讲几种实用、可落地的解决方式。
乐观锁：用版本号或时间戳判断是否被改过
适合读多写少、冲突概率低的场景（如用户资料修改、订单状态更新）。在表中加一个 version（整型）或 updated_at（时间戳）字段，更新时带上原始值作为条件：
UPDATE accounts SET balance = balance - 100, version = version + 1 WHERE id = 123 AND version = 5;
如果影响行数为 0，说明该记录已被其他事务更新，当前操作失效，应用层捕获后可提示用户“数据已变更，请刷新重试”或自动重载再提交。
- 版本号必须由数据库自增（如
version = version + 1），不能由应用计算后传入，否则可能覆盖他人更新 - 时间戳方式需确保精度足够（如用
NOW(6)微秒级），且注意时钟一致性问题 - 不适用于需要强一致递增计数的场景（如库存扣减），因版本本身不反映业务逻辑
悲观锁：显式加锁，让后续请求排队等
适合写频繁、冲突高、业务要求强一致的场景（如秒杀库存扣减、资金划账）。常用 SELECT ... FOR UPDATE 在事务内锁定目标行：
BEGIN; SELECT stock FROM products WHERE id = 1001 FOR UPDATE; -- 检查库存是否充足 UPDATE products SET stock = stock - 1 WHERE id = 1001; COMMIT;
注意：FOR UPDATE 锁的是索引键（非主键可能锁表），务必确保 WHERE 条件命中索引，否则易引发锁升级和性能问题。
- 锁持有时间越短越好，查询后尽快执行更新并提交，避免长时间阻塞
- MySQL 中若使用
READ COMMITTED隔离级别，锁只在当前语句生效；REPEATABLE READ下会持续到事务结束 - 应用需设置合理超时（如 JDBC 的
queryTimeout），防止死锁或长等待
原子更新 + 条件判断：用 SQL 自身能力规避应用层竞争
把“读-判-改”三步合并为一条带条件的 UPDATE，彻底消除中间态。例如扣库存，不允许超卖：
UPDATE products SET stock = stock - 1 WHERE id = 1001 AND stock >= 1;
执行后检查影响行数：为 1 表示成功扣减；为 0 表示库存不足或已被扣完。无需加锁，无版本字段，也无事务隔离依赖，简单高效。
- 适用于逻辑简单、判断条件能直接写进 WHERE 的场景（如余额大于某值、状态为待处理）
- 失败时需明确返回原因（比如通过
ROW_COUNT()或驱动提供的影响行数 API） - 不适合复杂校验（如需关联多张表判断），此时仍需事务+锁或应用层协调
分布式锁兜底：跨服务/跨库时的最终防线
当更新逻辑涉及多个数据库、微服务协同，或无法改造原有 SQL 结构时，可在应用层引入外部协调机制，如 Redis 分布式锁：
- 用
SET key value NX PX 10000获取锁，key 可设计为update:product:1001 - 获取成功后执行数据库操作，完成后主动释放锁（注意用 Lua 脚本保证原子性）
- 必须设过期时间防死锁，并考虑锁续期、可重入等细节
这不是首选方案——它增加系统复杂度和延迟，仅用于 SQL 层难以覆盖的边界情况。优先尝试前三种数据库原生手段。
