如何解决SQL Server中多用户同时执行INSERT带来的幻读问题

幻读并非由INSERT直接导致，而是“先查再插”业务逻辑在并发下暴露间隙漏洞；SERIALIZABLE仅对单条SELECT生效，无法覆盖多语句操作，且依赖索引与显式事务。

直接说结论：幻读不是 INSERT 本身造成的，而是“先查再插”这类业务逻辑在并发下暴露的间隙漏洞；SERIALIZABLE 能拦住部分场景，但治标不治本，且代价高。

为什么 SET TRANSACTION ISOLATION LEVEL SERIALIZABLE 不总管用

很多人设了 SERIALIZABLE 就以为万事大吉，结果还是出现重复插入。原因很实在：

• 它只对单条 SELECT 语句生效——如果你写的是 SELECT ...; IF NOT EXISTS ... INSERT ... 这种两步操作，中间那几十毫秒就是裸奔窗口
• 没索引时，SQL Server 会把 RangeS-S 锁升级成表锁，不仅没防住幻读，还把整个表堵死
• INSERT SELECT 中的子查询如果不显式加锁，隔离级别不会自动继承，照样漏
• 触发器里跑的隐式 SELECT 完全不受外层事务隔离级别约束

真正起效的写法：用原子性代替隔离级别

别靠“锁范围”去赌并发，直接让“判断 + 插入”变成一条不可拆分的操作：

• 用 MERGE 语句：MERGE INTO orders USING (VALUES (@id, @status)) AS src(id, status) ON src.id = orders.id WHEN NOT MATCHED THEN INSERT (id, status) VALUES (src.id, src.status); —— 内部自动加锁，不存在中间态
• 依赖唯一索引 + 错误捕获：建 UNIQUE (order_no)，然后直接 INSERT，遇到错误码 2627（违反唯一约束）就重试或忽略，比锁更轻量
• 用 UPDLOCK + HOLDLOCK 手动锁范围：SELECT 1 FROM orders WITH (UPDLOCK, HOLDLOCK) WHERE order_no = @no;，再 INSERT —— 粒度可控，且明确告诉 SQL Server：“我要在这儿写”

容易被忽略的底层依赖：索引和事务封装

上面所有方案都默认一个前提：你的查询条件能走索引。如果 WHERE status = 'pending' 对应的 status 列没建索引，HOLDLOCK 会变成表锁，SERIALIZABLE 会失效，MERGE 的性能也会断崖下跌。

另外，事务必须显式开启：BEGIN TRANSACTION，不能靠隐式事务或 autocommit 模式——否则锁一提交就释放，防护形同虚设。

真正卡住人的，从来不是隔离级别选哪个，而是“读-判-写”这三步有没有被真正绑成一个原子动作，以及支撑它的索引是否存在、是否被查询实际用到。