如何排查SqlException锁|通信缓冲区资源死锁故障

• 步骤1：确认全链路MAXDOP配置生效情况
  不要仅依赖语句级MAXDOP=1提示，先逐层检查配置优先级：
  • 执行SQL语句sp_configure 'show advanced options',1;RECONFIGURE;sp_configure 'max degree of parallelism'查看实例级最大并行度配置
  • 执行SELECT name, value FROM sys.database_scoped_configurations WHERE name = 'MAXDOP'查看数据库级并行度配置
  • 检查资源调控器工作负载组是否单独配置了MAXDOP限制
    可临时将实例级MAXDOP设为1观察24小时，若死锁不再出现即可定位为并行执行计划引发的通信缓冲区竞争，后续只需针对性优化相关查询的执行计划即可。
• 步骤2：核查数据库连接配置
  • 检查连接字符串中是否开启了MARS（Multiple Active Result Sets），如果配置了MultipleActiveResultSets=True建议先改为False测试。开启MARS后同一连接上运行多个未完成的异步查询时，极易出现通信缓冲区资源争抢，若业务需要同时执行多个查询，需为每个查询分配独立的数据库连接。
  • 检查连接池大小、连接超时配置，避免连接回收过程中出现的资源抢占。
• 步骤3：基于死锁XML定位根因
  • 在死锁XML中搜索waitresource字段，若值以CommunicationBuffer开头即可确认是并行查询线程间的死锁，再搜索executionStack字段获取死锁发生时所有进程正在执行的SQL语句。
  • 针对涉事SQL查询检查是否存在缺失索引，执行SELECT * FROM sys.dm_db_missing_index_details可查看官方缺失索引建议，添加覆盖索引让查询走索引seek而非全表/索引扫描，可从根源上避免不必要的并行执行计划生成。
• 步骤4：修复SQL Server 2016已知Bug
  你使用的SQL Server 2016存在多个官方确认的通信缓冲区死锁相关Bug，对应补丁在后续的累积更新（CU）中已修复，建议先将实例升级到SQL Server 2016 SP3 + 最新累积更新版本，再观察死锁是否复现。
• 步骤5：修正Dapper异步调用逻辑
  • 所有Dapper异步方法调用后添加.ConfigureAwait(false)，避免异步上下文切换过程中不必要的连接资源持有，示例：await connection.ExecuteAsync("<SQL语句>", entity).ConfigureAwait(false);
  • 确认同一IDbConnection实例同一时间仅执行一个查询，不要在单个连接上发起并行的异步查询操作，scoped生命周期的连接实例需确保请求内的多个查询串行执行。

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