SQL 并发更新冲突本质是多个事务同时尝试修改同一行数据，导致结果不可预期或丢失更新。核心解决思路是：**控制并发粒度、明确更新前提、及时发现并处理冲突**，而非单纯依赖数据库自动重试。
使用 WHERE 条件做乐观锁校验
在 UPDATE 语句中加入业务关键字段（如版本号 version 或时间戳 updated_at）作为条件，确保只更新“未被他人改过”的记录。执行后检查影响行数（rowcount），为 0 表示更新失败，需重试或提示用户。
例如：
UPDATE orders SET status = 'shipped', version = version + 1WHERE id = 123 AND version = 5;
应用层判断是否成功，若影响行为 0，则读取最新 version 后重试，或返回“数据已被修改”提示。
合理选用隔离级别与锁机制
避免盲目提升隔离级别。多数场景下，READ COMMITTED 已足够；高一致性要求可考虑 SELECT ... FOR UPDATE，但必须注意：
- 务必在事务内执行，且尽早加锁（避免先查后锁造成窗口期）
- 锁范围要精确（用主键或唯一索引，避免锁表或锁范围过大）
- 持有锁时间越短越好，不要在事务中做耗时操作（如调用外部 API、复杂计算）
将“读-改-写”合并为原子更新
能用单条 SQL 完成的逻辑，就不要拆成多步。例如计数器累加、状态机流转、金额增减等，优先使用：
- UPDATE ... SET col = col + 1 替代 SELECT + UPDATE
- INSERT ... ON CONFLICT DO UPDATE（PostgreSQL）或 INSERT ... ON DUPLICATE KEY UPDATE（MySQL）处理存在即更新场景
- 利用数据库函数（如 GREATEST、CASE WHEN）在 SQL 层完成条件判断，减少应用层逻辑介入
应用层配合：幂等设计与重试策略
数据库无法解决所有并发问题，应用层需兜底：
- 接口设计支持幂等（如用唯一业务 ID 做去重缓存或数据库唯一约束）
- 对可重试操作（如库存扣减、积分发放）设置有限次数+指数退避重试
- 对不可重试操作（如支付回调）采用最终一致性+补偿任务，而非强阻塞等待
