SQL Server并发INSERT/UPDATE操作引发死锁的处理方案咨询

一、先定位当前死锁的核心原因 #

虽然操作的是不同记录，但死锁大概率来自这几个点：

• 锁升级：SQL Server默认积累到5000个行锁时会升级成表锁，这时哪怕操作不同记录也会冲突。
• 非聚集索引竞争：比如UPDATE要更新非聚集索引键，或者INSERT时非聚集索引的页锁撞车，哪怕主键不同，索引页可能重叠。
• 事务拖得太长：API里的事务裹了太多无关操作（比如日志写入、第三方调用），锁持有的时间越久，死锁概率越高。
• 执行计划拉胯：UPDATE没走主键/唯一索引，导致全表扫描，锁了一堆无关行。

先做这几步排查：

• 开SQL Server的扩展事件跟踪死锁，拿到死锁图，明确是啥资源在抢。
• 看INSERT/UPDATE的执行计划，确认有没有用对索引，是不是全表扫描了。
• 检查事务范围，能不能把非数据库操作踢出事务，让事务快进快出。

二、无缝解决当前死锁的具体操作 #

1. 控制锁行为，避免锁升级 #

• 给表改锁升级设置：ALTER TABLE [你的表名] SET (LOCK_ESCALATION = DISABLE)，但大表频繁操作的话要注意，行锁太多会占内存，自己权衡。
• 或者在SQL语句里加ROWLOCK提示，强制用行级锁：UPDATE [表名] WITH (ROWLOCK) SET ... WHERE ...，减少锁升级触发的概率。

2. 优化索引设计 #

• 确保UPDATE的WHERE条件用主键或唯一索引，别让数据库扫全表锁一堆行。
• 少在高频更新的列上建非聚集索引，或者调整索引填充因子，减少页分裂导致的锁冲突。
• INSERT用自增主键的话，索引页分配是连续的，能降低页锁竞争。

3. 把事务缩到最小 #

• API里的事务只包必要的SQL操作，别把日志、第三方调用这些塞进去，让事务尽快提交，锁持有的时间越短越好。
• 用乐观并发控制：给表加个ROWVERSION（或TIMESTAMP）列，更新时先检查版本是否一致，不用长时间持有锁。示例：

  UPDATE [表名] 
  SET [列名] = @新值
  WHERE [主键] = @主键 AND [RowVersion] = @当前版本
  

  如果返回行数是0，说明数据被改了，重试就行。

4. 改隔离级别（无缝首选） #

默认的READ COMMITTED隔离级别会把共享锁持到事务结束，改成READ COMMITTED SNAPSHOT ISOLATION（RCSI），用行版本控制，避免共享锁堵更新：

ALTER DATABASE [你的数据库名] SET READ_COMMITTED_SNAPSHOT ON;

这个是数据库层面的调整，不用改应用代码，完全无缝，优先试试这个。

三、并发Web应用死锁通用处理方案 #

1. 重试机制（最常用） #

死锁是偶发的，捕获SQL Server的1205错误号，自动重试3-5次就行。比如在API代码里用try-catch抓这个错误，然后重新执行SQL操作。

2. 统一操作顺序 #

如果一个事务要操作多个表或多行，所有事务都按同一个顺序来，比如先改表A再改表B，或者先改主键小的行再改大的，避免循环等待搞出死锁。

3. 队列机制的适用情况和实现 #

队列不是必须的，但如果并发量一直很高，或者业务允许延迟处理，能有效降低直接写库的压力：

• 适合场景：比如审计日志插入、非实时的更新操作，不需要立刻返回结果的业务。
• 实现方式：
  • 用SQL Server自带的Service Broker，把INSERT/UPDATE请求丢队列里，后台用作业或服务异步处理。
  • 用AWS SQS队列，API先把请求发去SQS，再用Lambda或ECS服务异步消费队列执行数据库操作。
  • 一定要做幂等：每个请求加唯一ID，处理前先查有没有执行过，避免重复操作。

四、总结 #

当前场景优先用开启RCSI隔离级别、优化索引和事务范围、加重试机制这几个方案，不用大改代码就能无缝解决。要是后续并发量还涨，或者业务允许延迟，再上队列。

内容的提问来源于stack exchange，提问作者Shruti