基于EF6与SQL Server 2019的.Net MVC应用死锁问题求解

现有方案评估 #

• 方案1（开启SQL Server快照隔离）：你担心的tempdb膨胀问题可通过提前预分配tempdb多数据文件、设置合理的自动增长步长规避，2TB数据库只要不存在全表高频批量更新的场景，行版本生成量远低于预期，预留20%-30%的tempdb存储空间即可覆盖高峰期需求。该方案改造成本最低，仅需执行2条SQL命令即可全局生效，无需修改业务代码：

  ALTER DATABASE [你的业务库名] SET ALLOW_SNAPSHOT_ISOLATION ON;
  ALTER DATABASE [你的业务库名] SET READ_COMMITTED_SNAPSHOT ON;
  

• 方案2（ReadCommitted隔离级别包裹查询）：无需修改600行业务查询代码，可通过EF6全局配置统一生效，仅需在DbContext构造函数中添加一行代码，或者实现EF命令拦截器全局设置，总改动量不超过10行：

  // DbContext构造函数中添加
  Database.ExecuteSqlCommand("SET TRANSACTION ISOLATION LEVEL READ COMMITTED;");
  

• 方案3（改写为带nolock的存储过程）：不推荐，nolock提示会引入脏读、重复读、幻读等数据一致性问题，对业务数据准确性影响较大，且存储过程改写后后续业务迭代的维护成本远高于EF原生查询。

额外适配建议 #

• 优先定位死锁根源：抓取SQL Server的死锁日志，确认死锁触发的根因。如果是索引缺失导致查询/更新触发全表扫描、锁升级为表锁，优先补充对应的非聚集索引，90%的业务场景死锁可通过索引优化解决，无需修改业务逻辑。
• 只读查询开启非跟踪模式：所有不需要更新的EF查询添加AsNoTracking()方法，既可以减少EF上下文的锁持有时间，也能提升查询性能：

  // 示例
  var list = dbContext.业务表名.AsNoTracking().Where(过滤条件).ToList();
  

• 拆分大事务：梳理现有更新逻辑，把非核心操作移出事务范围，尽可能缩短事务持有锁的时间，高峰期长事务是死锁高发的核心诱因之一。
• 配置死锁优先级：对于非核心的查询逻辑，可单独设置低死锁优先级，确保核心更新操作不会被死锁牺牲：

  SET DEADLOCK_PRIORITY LOW;
  

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