聚合查询本身不直接锁表，但置于事务中或高隔离级别下易持共享锁甚至升级排他锁而阻塞写操作；解决关键在于控制其事务位置与上下文环境。
聚合查询本身不直接锁表，但放在事务里、或配合高隔离级别时，很容易把 SELECT 变成长期持有共享锁甚至升级为排他锁，进而阻塞写操作。 解决核心不是“怎么写聚合”，而是控制它在事务中的位置和上下文环境。
为什么聚合查询会意外锁表
常见于以下组合：
-
SELECT COUNT(*) FROM orders WHERE status = 'pending'放在BEGIN TRANSACTION里，且事务未及时提交 —— 这个查询在可重复读（REPEATABLE READ）下会加范围锁，阻止新记录插入满足条件的行 - 聚合语句没走索引（如
WHERE created_date > GETDATE() - 7但该字段无索引），导致全表扫描 + 大量页锁，锁资源堆积 - 用
WITH (TABLOCK)或WITH (HOLDLOCK)显式提示，本意是保证一致性，结果锁了整张表
减小事务范围：别让聚合“拖累”整个业务流程
聚合查询通常只读，不该和 UPDATE、INSERT 绑在同一事务里。否则一个慢聚合会让后续写操作排队，甚至触发死锁。
- 把聚合逻辑拆出来：先查总数，再开新事务做业务更新，中间不保留事务上下文
- 避免在存储过程中用
@@TRANCOUNT > 0判断是否已存在事务，然后“顺手”把聚合也包进去 - 如果必须在事务中查聚合（例如校验余额后扣款），改用快照隔离（
READ COMMITTED SNAPSHOT），让读不加锁
降低隔离级别：读操作不必强一致时，别硬扛默认设置
SQL Server 默认是 READ COMMITTED，但很多场景下，聚合只是给报表或监控用，几秒延迟可接受。
- 显式指定
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED，跳过共享锁 —— 注意可能读到未提交数据，但对统计类聚合影响极小 - 更稳妥的是启用数据库级快照：执行
ALTER DATABASE [db_name] SET READ_COMMITTED_SNAPSHOT ON，之后所有READ COMMITTED查询自动走行版本，不阻塞也不被阻塞 - 别用
NOLOCK提示写满每个查询：它绕过锁但也会跳过删除标记，极端情况下漏计数；优先用会话级或连接级隔离设置
容易被忽略的细节
即使做了上述调整，如果聚合语句本身走不了索引，还是会引发大量页锁或键锁。务必检查执行计划里的 Index Seek / Index Scan 类型，以及 Estimated Number of Rows 是否远超实际。一个没索引的 COUNT(*) 在千万级表上，哪怕只读，也可能持续锁住几百页几十秒 —— 这时候降隔离级别也没用，得先补索引。
