高并发下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)或在事务中执行，照样会申请锁——锁和跟踪是两回事
