SQL并发更新冲突核心是行锁竞争与等待，需从锁持有者、等待者、类型及事务上下文四方面排查，结合各数据库锁视图定位阻塞链，确保WHERE条件命中索引以避免锁升级，并控制事务粒度与时长，规避读-改-写、无索引更新等典型冲突模式。
SQL并发更新冲突的核心在于行锁竞争与锁等待，尤其在高并发写入场景下，事务相互阻塞会导致响应延迟、超时甚至死锁。排查需从锁的持有者、等待者、锁类型和事务上下文四方面入手。
确认当前锁等待状态
通过数据库系统视图定位正在等待锁的会话及被阻塞的SQL：
- MySQL：查询 performance_schema.data_lock_waits（8.0+）或 information_schema.INNODB_TRX 与 INNODB_LOCK_WAITS 关联分析；
- PostgreSQL：查 pg_stat_activity 中 wait_event_type = 'Lock'，再关联 pg_locks 和 pg_stat_statements 定位阻塞链；
- SQL Server：使用 sys.dm_exec_requests 中 blocking_session_id > 0 找出被阻塞会话，再结合 sys.dm_tran_locks 查锁资源。
识别锁竞争的热点行与索引
行锁是否生效，取决于WHERE条件能否命中索引。全表扫描或索引失效将升级为间隙锁或表锁，大幅扩大锁范围：
- 执行 EXPLAIN（MySQL/PostgreSQL）或 SET STATISTICS XML ON（SQL Server），确认UPDATE语句是否走了索引扫描；
- 检查WHERE字段是否有合适索引，特别是联合索引顺序是否匹配查询条件（如 UPDATE t SET x=1 WHERE a=1 AND b=2，索引应为 (a,b) 而非 (b,a)）；
- 注意唯一索引与非唯一索引的锁行为差异：唯一索引等值查询只锁匹配行；非唯一索引可能触发间隙锁，导致相邻记录也被锁定。
分析事务粒度与持有时间
长事务是锁等待的温床——锁不会在语句结束就释放，而要等到事务提交或回滚：
- 检查事务中是否混入了慢查询、远程调用、文件读写等非DB操作，人为拉长锁持有时间；
- 避免在事务内执行应用层逻辑，尤其是循环更新多条记录时，考虑拆分为单行事务或使用批量UPSERT（如MySQL INSERT ... ON DUPLICATE KEY UPDATE）；
- 设置合理事务超时（如Spring的@Transactional(timeout=5)），防止悬挂事务长期占锁。
验证与规避典型冲突模式
以下场景极易引发隐性竞争，需针对性验证：
- “读-改-写”未加锁：如先SELECT再UPDATE，中间可能被其他事务修改。应改用带条件的UPDATE（UPDATE t SET cnt=cnt+1 WHERE id=123 AND version=5）或SELECT FOR UPDATE；
- 无主键/无索引更新：导致全表扫描加锁，所有行都被锁定。务必确保UPDATE语句WHERE子句有高效索引支撑；
- 自增主键插入后的UPDATE：某些ORM在save后立即根据ID更新，若ID生成与更新不在同一事务，可能因并发插入导致幻读或锁等待。
