我捕获了 SQL Server 2012 死锁图（使用盖尔·肖的 https://www.red-gate.com/simple-talk/sql/performance/sql-server-deadlocks-by-example/查询），显示一个任务优先级=“10”的进程被选为两个任务优先级=“0”的进程的死锁受害者。
我的理解是，首先检查死锁优先级，然后选择较低优先级的进程作为受害者。只有当所有进程都具有同等优先级时，其他因素才会相关。任何人都可以解释为什么 DEADLOCK_PRIORITY 可能不被尊重吗？
有趣的是，设置 DEADLOCK_PRIORITY https://learn.microsoft.com/en-us/sql/t-sql/statements/set-deadlock-priority-transact-sqlMSDN页面说HIGH映射到5，而我的代码肯定使用HIGH，所以我不确定10来自哪里。
令人烦恼的是，受害者是一个重要的业务流程，而幸存者都是 SSMS Intellisense 查询。
Edit
首先，这个问题是关于为什么 DEADLOCK_PRIORITY 不会被遵守，而不是什么是死锁，或者如何防止死锁或解决死锁，或者是什么导致了下面示例中的死锁。这些都是有趣的对话，但不是这里。
其次，根据@SteveFord 找到的链接，还有一些可能相关的其他事实；该SQL Server启用了锁分区，且SQL Server版本早于2012 CU6（KB2776344补丁发布时）。
第三，对于那些感兴趣的人来说，这是一个经过清理的死锁图，显示了较高优先级的进程被选为受害者。我删除了 SQL 并更改了一些名称，其他一切都完好无损。
<deadlock>
<victim-list>
<victimProcess id="process5f390c8" />
</victim-list>
<process-list>
<process id="process5f390c8" taskpriority="10" logused="3200" waitresource="KEY: 6:281474978938880 (655334c51469)" waittime="1806" ownerId="296690694" transactionname="ALTER PARTITION FUNCTION" lasttranstarted="2018-01-29T11:59:36.140" XDES="0x886312d28" lockMode="X" schedulerid="9" kpid="32684" status="suspended" spid="86" sbid="0" ecid="0" priority="5" trancount="1" lastbatchstarted="2018-01-29T11:58:38.310" lastbatchcompleted="2018-01-29T11:58:38.310" lastattention="1900-01-01T00:00:00.310" clientapp="CLIENTAPP" hostname="HOSTNAME" hostpid="10912" loginname="DOMAIN\USERNAME" isolationlevel="read committed (2)" xactid="296690694" currentdb="6" lockTimeout="4294967295" clientoption1="673187936" clientoption2="128056">
<executionStack>
<frame procname="adhoc" line="2" stmtstart="138" sqlhandle="0x01000600a1f28605207939860500000000000000000000000000000000000000000000000000000000000000">
...removed...</frame>
<frame procname="mssqlsystemresource.sys.sp_executesql" line="1" stmtstart="-1" sqlhandle="0x0400ff7f427f99d9010000000000000000000000000000000000000000000000000000000000000000000000">
...removed...</frame>
<frame procname="SUBSPNAME" line="75" stmtstart="5434" stmtend="5502" sqlhandle="0x0300060011b27f3d08e76c012ba8000001000000000000000000000000000000000000000000000000000000">
...removed...</frame>
<frame procname="SPNAME" line="65" stmtstart="4234" stmtend="4516" sqlhandle="0x030006004990de353efaf70071a8000001000000000000000000000000000000000000000000000000000000">
...removed...</frame>
<frame procname="adhoc" line="1" sqlhandle="0x01000600679e2e28907739860500000000000000000000000000000000000000000000000000000000000000">
...removed...</frame>
</executionStack>
<inputbuf>
...removed...</inputbuf>
</process>
<process id="process791872558" taskpriority="0" logused="0" waitresource="OBJECT: 6:139251651:11 " waittime="8299" ownerId="300839454" transactionname="MDView" lasttranstarted="2018-01-29T12:19:33.727" XDES="0x4cddd58a0" lockMode="Sch-S" schedulerid="9" kpid="20372" status="suspended" spid="75" sbid="0" ecid="0" priority="0" trancount="0" lastbatchstarted="2018-01-29T12:19:33.720" lastbatchcompleted="2018-01-29T12:19:33.713" lastattention="2018-01-29T12:19:18.360" clientapp="Microsoft SQL Server Management Studio" hostname="ANOTHERHOSTNAME" hostpid="62236" loginname="DOMAIN\ANOTHERUSERNAME" isolationlevel="read committed (2)" xactid="300839326" currentdb="6" lockTimeout="10000" clientoption1="671090784" clientoption2="128056">
<executionStack>
<frame procname="adhoc" line="1" stmtstart="56" sqlhandle="0x02000000c7bca00d097183e2d5dd8e6785f452180936fd930000000000000000000000000000000000000000">
...removed...</frame>
<frame procname="unknown" line="1" sqlhandle="0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000">
...removed...</frame>
</executionStack>
<inputbuf>
...removed...</inputbuf>
</process>
</process-list>
<resource-list>
<keylock hobtid="281474978938880" dbid="6" objectname="DBNAME.sys.sysschobjs" indexname="clst" id="lock1ef508c700" mode="U" associatedObjectId="281474978938880">
<owner-list>
<owner id="process791872558" mode="S" />
</owner-list>
<waiter-list>
<waiter id="process5f390c8" mode="X" requestType="convert" />
</waiter-list>
</keylock>
<objectlock lockPartition="11" objid="139251651" subresource="FULL" dbid="6" objectname="TABLENAME" id="lock398e43e00" mode="Sch-M" associatedObjectId="139251651">
<owner-list>
<owner id="process5f390c8" mode="Sch-M" />
</owner-list>
<waiter-list>
<waiter id="process791872558" mode="Sch-S" requestType="wait" />
</waiter-list>
</objectlock>
</resource-list>
</deadlock>
看起来被杀死的命令是一个 ALTER PARTITION FUNCTION，有趣的是，这需要一个 SCH-M 锁，它与用于所有操作的 SCH-S 锁不兼容。我想这可能是一个原因。
See michaeljswart.com/2013/04/the-sch-m-lock-is-evil http://michaeljswart.com/2013/04/the-sch-m-lock-is-evil/.
另请参阅来自 ALTER PARTITION 函数的 SCH-M 死锁的描述以及导致 SQL 2014 和 2016 中统计信息更新的查询，但在 2012 年也可能是这样：获取 SCH-M 锁时发生死锁 https://support.microsoft.com/en-gb/help/3174476/fix-deadlock-occurs-when-you-acquire-a-sch-m-lock-and-alter-a-partitio
查看您的图表，一个进程在 sysschobjs 上有一个共享（更新）锁，并且正在等待您的表上的 SCH-S 锁。您的进程在表上有 SCH-M 锁，并且正在等待 sysschobjs 上的 X 锁。 sysschobjs 是位于 sysobjects 后面的系统基表。请参阅此处的讨论Technet：经常导致死锁的 SQL 查询 https://social.technet.microsoft.com/Forums/ie/en-US/741a7463-b755-49ed-bbd9-70b7379033f1/sql-query-that-causes-deadlock-often?forum=sqldatabaseengine
希望这可以帮助
更新
如果你想进一步研究这个问题，我找到了关于死锁监视器如何选择受害者的 MS 专利描述here https://www.google.tl/patents/US9104989
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
