设置Deadlock_Priority为LOW后作业仍成死锁牺牲品的问题咨询

首先纠正一个可能的误解：SET DEADLOCK_PRIORITY LOW是降低当前会话的死锁优先级，会让这个会话更容易被选为死锁牺牲品，而不是避免成为牺牲品——这可能是你困惑的核心原因之一。

接下来直接回答你的核心问题：SQL Server的死锁优先级是会在子过程链中继承的。当你在作业步骤里设置了死锁优先级后，后续调用的存储过程Client_myDeliveries_I_S会完全继承这个会话级别的设置，不会因为进入存储过程就重置优先级。

那为什么你的存储过程还是出现在死锁牺牲品栈中？结合你的描述，大概率是这两个原因：

• 你设置的是LOW优先级，而参与死锁的另一个会话用的是默认的NORMAL（或更高的HIGH）优先级：SQL Server在选择死锁牺牲品时，会优先挑优先级更低的会话，所以你的会话被选中完全符合规则。
• 即使优先级相同，SQL Server也会选择回滚代价更低的会话（比如修改行数更少、日志量更小）作为牺牲品，但你这里明确设了LOW，所以优先级因素是主导原因。

你可以在完整的死锁XML里查找deadlockpriority字段，确认牺牲品会话的实际优先级数值（LOW对应-5，NORMAL对应0），就能验证优先级继承是否生效了。

如果你想避免作业会话成为牺牲品 #

如果你的目标是让作业会话尽量不被选为牺牲品，应该设置更高的优先级，比如：

DECLARE @deadlock_var NCHAR(4); 
SET @deadlock_var = N'HIGH'; 
SET DEADLOCK_PRIORITY @deadlock_var;
-- 调用存储过程
exec Client_myDeliveries_I_S

或者直接用数值简化设置：SET DEADLOCK_PRIORITY 5;（对应HIGH优先级）。

当然，更彻底的解决思路是排查死锁根源：通过完整死锁XML分析两个会话的锁资源、执行路径，调整查询逻辑（比如加合适的索引、缩短事务时长、统一锁获取顺序），从源头避免死锁发生。

内容的提问来源于stack exchange，提问作者cloudsafe