快照隔离不能直接解决死锁，因为它不改变写操作的排他锁行为和锁申请顺序，仅消除读-写冲突；写-写冲突仍会导致1205错误，且对UPDLOCK等显式锁提示无效。
SERIALIZABLE 和 REPEATABLE READ 隔离级别会显著放大死锁概率，而 SNAPSHOT 隔离不是“避免死锁”的银弹，它是通过消除读写冲突来间接降低死锁发生率——但前提是必须正确启用并配合事务结构改造。
为什么快照隔离（SNAPSHOT）不能直接“解决”死锁
死锁本质是两个事务对相同资源以不同顺序加锁形成的循环等待。快照隔离不改变锁申请顺序，也不影响 UPDATE、DELETE 对数据行的排他锁（X 锁）行为；它只让 SELECT 不再申请共享锁（S 锁），而是读取事务开始时的版本化数据。这意味着：
- 读-写冲突（如
SELECT ... FROM orders等待UPDATE orders）消失 → 这类场景下死锁大幅减少 - 写-写冲突（两个
UPDATE同时改同一行）依然存在 → 仍会触发 1205 错误 - 如果存储过程中有
SELECT WITH (UPDLOCK)或显式锁提示，快照隔离对其无效 —— 它们仍走锁路径
启用 SNAPSHOT 隔离前必须做的三件事
跳过任一环节，不仅死锁照旧，还可能引发版本存储区（tempdb）暴涨、查询性能下降甚至阻塞。
- 数据库级开关必须打开：
ALTER DATABASE [YourDB] SET ALLOW_SNAPSHOT_ISOLATION ON（仅此不够） - 必须同时启用
READ_COMMITTED_SNAPSHOT ON（否则普通SELECT仍走锁，且SNAPSHOT事务内无法读到其他已提交变更） - 所有涉及高并发更新的存储过程，需显式声明：
SET TRANSACTION ISOLATION LEVEL SNAPSHOT—— 不能依赖连接默认级别
哪些存储过程适合改用 SNAPSHOT，哪些反而更危险
盲目切换隔离级别可能让问题从“死锁”变成“写覆盖”或“逻辑错误”，关键看业务语义是否允许读取旧版本。
- ✅ 适合：订单状态轮询类（
SELECT status WHERE order_id = @x）、报表统计（读历史快照无妨）、日志归档（只读不写） - ❌ 危险：库存扣减（
SELECT qty后UPDATE qty = qty - 1）—— 若两个事务同时读到 qty=10，都会扣成9，导致超卖 - ⚠️ 需重构：任何“先查后更”逻辑必须改用原子操作，例如把
IF NOT EXISTS(SELECT)+INSERT换成MERGE或带UPDLOCK, HOLDLOCK的单条SELECT
SNAPSHOT 下仍报 1205？立刻检查这三点
出现这种情况，说明问题根本不在读锁，而在写锁竞争本身。此时快照隔离已无能为力，必须回归锁序和索引优化。
- 执行计划是否走了全表扫描？
UPDATE没命中索引 → 锁住整页甚至整表 → 冲突面指数级扩大 - 事务中是否调用了外部对象？如
OPENQUERY、EXEC xp_cmdshell、CLR 函数 —— 它们强制事务脱离快照上下文，回退到锁模式 - 是否混用了
NOLOCK和SNAPSHOT？前者绕过版本控制读脏数据，后者依赖版本链；两者共存会破坏一致性假设
真正难处理的死锁，往往藏在你认为“只是读一下”的那句 SELECT 后面——它没加锁，但触发了触发器、外键级联或未建索引的 JOIN，悄悄拉进了第三张表。快照隔离能帮你盖住表层噪音，但盖不住底层资源争抢的物理事实。
