17370845950

高并发下UPDATE无WHERE会触发表锁；TransactionScope默认Serializable导致间隙锁；EF Core批量SaveChanges引发页锁；连接池耗尽常是锁问题的表象。

高并发下 UPDATE 语句没加 WHERE 条件会触发表锁

SQL Server 在执行没有有效索引匹配的 UPDATE 或 DELETE 时，可能升级为表级锁（TABLE 锁），尤其当扫描行数超过阈值（如 5000 行）或优化器判断全表扫描更“划算”时。C# 应用中若使用 DbContext.SaveChanges() 修改大量未筛选实体，或手写 SQL 忘记 WHERE，就会让整个表卡住。

• 典型现象：sp_who2 查到大量 WAIT 状态，BlockedBy 指向一个 KEY 或 OBJECT 锁持有者，而该持有者正执行无条件更新
• 验证方式：用 SELECT * FROM sys.dm_tran_locks WHERE resource_type = 'OBJECT' 查看是否出现 OBJECT 级 U（update）或 X（exclusive）锁
• 修复动作：确保所有 UPDATE 都有 SARGable 的 WHERE 条件，并在对应列上建好索引（比如 WHERE OrderStatus = 'Pending' → 在 OrderStatus 列建非聚集索引）

C# 中 TransactionScope 默认隔离级别引发长时间行锁等待

TransactionScope 默认使用 Serializable 隔离级别（SQL Server 后端实际表现为 REPEATABLE READ 或更高），它不仅锁住查到的行，还会锁住“可能插入新行”的间隙（gap lock），导致看似无关的插入/更新也被阻塞。

• 常见错误：在循环里

  

  开 TransactionScope 处理每条订单，且事务内含 SELECT ... FOR UPDATE 类逻辑（如 EF 的 AsNoTracking().FirstOrDefault() + 后续修改），但事务未及时 Complete()
• 影响范围：即使只更新单行，也可能因间隙锁锁住整页，让其他线程对相邻主键值的插入失败并超时
• 建议做法：

  using (var scope = new TransactionScope(TransactionScopeOption.Required,
      new TransactionOptions { IsolationLevel = IsolationLevel.ReadCommitted }))
  {
      // 数据库操作
      scope.Complete();
  }

  显式降级到 ReadCommitted，配合行版本控制（READ_COMMITTED_SNAPSHOT ON）可进一步消除读写互斥

EF Core 的 SaveChanges 批量提交引发隐式锁竞争

EF Core 默认把同一 SaveChanges() 调用中的多个实体变更合并成一条批处理语句（如多行 INSERT / UPDATE）。如果这批操作涉及不同主键但相同索引页（比如时间戳相近的订单插入到聚集索引末尾），SQL Server 可能对整页加 KEY 锁，造成“伪热点”。

• 典型表现：压测时吞吐卡在某个值，sys.dm_os_waiting_tasks 显示大量 LCK_M_U 等待，等待资源是 PAG: 12:1:123456（页锁）
• 缓解方式：

  context.BulkInsert(entities); // 使用 Z.EntityFramework.Extensions 等支持分批的库
  // 或手动拆分：
  foreach (var batch in entities.Chunk(100))
  {
      context.AddRange(batch);
      await context.SaveChangesAsync();
  }

  避免单次提交过大批次；同时考虑将聚集索引换成非自增列（如 GUID 分散写入，但需权衡查询性能）
• 注意：EF Core 7+ 的 ExecuteUpdateAsync 直接生成 SQL，不走 ChangeTracker，锁行为更可控，适合确定性批量更新场景

连接池耗尽掩盖真实锁问题

当数据库锁等待时间过长，C# 应用的 SqlConnection 会在连接池中持续占用连接，最终触发 Timeout expired. The timeout period elapsed prior to obtaining a connection from the pool。此时你看到的是连接池异常，但根因是上游某条慢查询/长事务占着行锁不放。

• 排查路径：先查 sys.dm_exec_sessions 中 status = 'sleeping' 但 last_request_end_time 很旧的会话，再关联 sys.dm_tran_locks 看它持有哪些锁
• 关键配置：Connection Timeout=30 和 Max Pool Size=100 不要盲目调大，应优先缩短事务执行时间（如把日志写入、HTTP 调用等 I/O 操作移出事务）
• 容易被忽略的点：Entity Framework 的 AsNoTracking() 虽不参与变更跟踪，但如果查询本身带 WITH (UPDLOCK) 或在事务中执行，照样会申请锁——锁和跟踪是两回事