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