幻读并非由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 模式——否则锁一提交就释放，防护形同虚设。
真正卡住人的，从来不是隔离级别选哪个，而是“读-判-写”这三步有没有被真正绑成一个原子动作，以及支撑它的索引是否存在、是否被查询实际用到。
