SQL Server中聚合查询本身不直接导致幻读，但可重复读隔离级别下因间隙未被锁定，新插入/删除行会导致多次聚合结果不一致；根本解法是根据场景选用SERIALIZABLE、RCSI或谨慎的手动锁策略。
SQL Server 中聚合查询本身不会直接导致幻读，但幻读可能在可重复读（REPEATABLE READ）隔离级别下被误判——真正需要防范的是在事务中多次执行 SUM、COUNT 等聚合时，因新插入/删除行而得到不一致结果。根本解法不是盲目调高隔离级别，而是明确场景、选对锁策略或改用快照隔离。
为什么 REPEATABLE READ 无法阻止聚合幻读
SQL Server 的 REPEATABLE READ 会锁定已读取的行（key lock），但不锁定“不存在的行”——即 gap（间隙）。当另一个事务在两次 COUNT(*) 之间插入满足 WHERE 条件的新行，第二次聚合就会多出记录，这就是幻读现象。
常见错误现象：
- 事务 A 执行
SELECT COUNT(*) FROM orders WHERE status = 'pending'得到 12 - 事务 B 插入一条
status = 'pending'的新订单并提交 - 事务 A 再次执行相同
COUNT(*)，返回 13 —— 这就是幻读
此时即使加了 WITH (HOLDLOCK)，若没覆盖完整搜索范围（如缺少索引支撑），仍可能漏锁间隙。
用 SERIALIZABLE 隔离级别锁住整个范围
SERIALIZABLE 是 SQL Server 唯一能真正防止幻读的内置隔离级别，它会对扫描范围加范围锁（RangeS-S 或 RangeI-N），阻止其他事务在该范围内插入/删除。
实操建议：
- 仅在明确需要强一致性且并发写入不频繁的场景启用，比如财务对账、库存预占等关键业务
- 必须确保查询有合适的索引（例如
WHERE status = 'pending'字段上有索引），否则会升级为表锁，严重阻塞 - 避免在长事务中使用，锁持有时间越长，冲突概率越高
- 开启方式：
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE，需在事务开始后、第一个语句前执行
示例：
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE; BEGIN TRAN; SELECT COUNT(*) FROM orders WITH (HOLDLOCK) WHERE status = 'pending'; -- 其他逻辑... COMMIT;
更轻量的替代方案：启用 READ_COMMITTED_SNAPSHOT
如果服务器允许修改数据库级配置，开启 READ_COMMITTED_SNAPSHOT（RCSI）是更推荐的做法。它让所有 READ COMMITTED 查询自动基于行版本控制（tempdb 中的版本记录）读取快照，天然规避幻读（以及不可重复读、脏读），且不加锁。
注意点：
- 启用后，原
READ COMMITTED行为不变，但底层不再用共享锁，而是读取事务启动时刻的已提交版本 - 聚合查询在 RCSI 下仍是“事务内一致性”，两次
COUNT返回相同结果（因为看到同一时间点的快照） - 代价是 tempdb 压力增大，尤其在高更新频率场景；需监控
version_ghost_record_count和tempdb空间增长 - 启用命令：
ALTER DATABASE [YourDB] SET READ_COMMITTED_SNAPSHOT ON（需单用户模式或无活跃连接）
聚合查询中手动加锁的边界情况
有时你只想临时保护某次聚合，又不想改全局隔离级别或数据库配置。这时可用 UPDLOCK + HOLDLOCK 组合模拟范围锁效果，但效果依赖执行计划和索引。
关键限制：
-
WITH (HOLDLOCK)在聚集索引扫描时才可能升级为范围锁；若走堆表或非覆盖索引，可能只锁住具体行，不锁间隙 - 必须配合
UPDLOCK（而非ROWLOCK）才能触发范围锁机制，例如：SELECT COUNT(*) FROM orders WITH (UPDLOCK, HOLDLOCK) WHERE status = 'pending' - 没有合适索引时，SQL Server 可能选择表锁，反而放大阻塞
- 该方式不可靠，仅适用于简单、稳定、索引完备的 OLTP 小型聚合，生产环境慎用
真正容易被忽略的是：幻读是否真的影响业务？很多所谓“不一致”的聚合结果，其实只是统计延迟，未必需要强一致性。先确认业务 SLA 是否真要求“两次聚合绝对相等”，再决定上锁还是接受快照语义。
