在SQL Server 2019中如何避免MERGE语句的并发死锁Bug？-SQL-PHP中文网

merge在sql server 2019中易触发死锁，因其默认以不可预测顺序加锁：可能先锁非聚集索引再回表锁聚集索引，而并发merge反向加锁，形成循环等待；需用using子句中加updlock+holdlock强制统一锁序，或拆分为有序insert+update。

在sql server 2019中如何避免merge语句的并发死锁bug？

为什么MERGE在SQL Server 2019中容易触发死锁

MERGE语句本身不是“Bug”，但在SQL Server 2019（及更早版本）中，它默认以不可预测的锁顺序访问源和目标表，尤其当目标表有多个索引、且WHERE条件未精准命中唯一键时，MERGE可能先获取非聚集索引上的排他锁，再回表请求聚集索引锁——而另一个并发MERGE可能按相反顺序加锁，形成循环等待。这与“多表更新顺序不一致”的经典死锁场景完全一致。

用`UPDLOCK` + `HOLDLOCK`强制锁顺序

最直接有效的缓解方式，是在MERGE的USING子句中对源数据显式加锁，让所有并发执行都按同一路径申请锁：

MERGE target_table AS t
USING (SELECT id, value FROM source_data WITH (UPDLOCK, HOLDLOCK)) AS s
  ON t.id = s.id
WHEN MATCHED THEN UPDATE SET t.value = s.value
WHEN NOT MATCHED THEN INSERT (id, value) VALUES (s.id, s.value);

关键点：

UPDLOCK防止其他会话对同一行做UPDATE或MERGE，避免“读-改-写”窗口期
HOLDLOCK等价于SERIALIZABLE，把扫描范围锁住，防止幻读引发的锁重排
必须加在USING的子查询上，而不是target_table；加在目标表上无效且可能扩大锁粒度
如果源是临时表或CTE，需先物化（例如插入#temp），再对其加锁——CTE无法直接加WITH提示

替代方案：拆成`INSERT` + `UPDATE`并统一访问顺序

当业务允许时，显式拆分比MERGE更可控。重点在于确保所有路径都按相同物理顺序访问目标行：

用SELECT ... ORDER BY id驱动后续操作（即使逻辑无需排序，也强制SQL Server按该顺序加锁）
UPDATE和INSERT分开执行，中间不混杂其他DML
对目标表的WHERE条件字段必须有覆盖索引，避免全表扫描导致锁行数爆炸
若涉及多列匹配（如WHERE a=@a AND b=@b），索引必须是(a, b)或(b, a)之一，并在所有代码中严格保持列顺序一致

SQL Server 2019是否支持优化锁定？

不支持。OPTIMIZE_FOR_SEQUENTIAL_KEY和优化锁定（TID/LAQ）都是SQL Server 2022+ 和 Azure SQL 才引入的特性。SQL Server 2019仍使用传统锁管理器，MERGE的锁行为不会因数据库选项自动改善。即使启用READ_COMMITTED_SNAPSHOT，它只缓解读阻塞，对MERGE中的写冲突无实质帮助——因为MERGE的匹配判断和变更操作仍需真实行锁。

真正容易被忽略的是：哪怕你加了UPDLOCK，如果源数据来自未索引视图或函数，SQL Server仍可能选择低效执行计划，绕过你的锁意图。务必检查实际执行计划里的Seek/Scan类型和锁资源提示。