我遇到了一个死锁场景，死锁的唯一参与者似乎是一个表和一个从该表中删除的存储过程。我根据对其中几个死锁时的 sql 错误日志的分析得出了这个结论，并使用下面的 MSDN 文章作为破译错误日志中的跟踪的指南。

下面定义了表 DEXTable 和存储过程 ClearDEXTableRows。还有另一个存储过程 InsertDEXTableRow 将行插入 DEXTable，但是根据 sql 错误日志中的条目，该过程似乎没有涉及死锁。

DEXTable 中有大约 830 万行，并且趋于稳定增长。受访者表也很大，并且趋于稳定增长。

它是从具有频繁快速连续调用 ClearDEXTableRows 和 InsertDEXTableRow 的页面的高流量网站访问的。

在过去的 10 天内，每天发生 0 到 9 次死锁。

我已经为 1222（使用 DBCC TRACEON 1222）启用了 sql 跟踪，并且最近启用了标志 1204。在检测和结束死锁上有对这些标志的输出的很好的描述

我的问题是：

只有这个存储过程 ClearDEXTableRows 是导致死锁的原因是否有意义？

如果是这样，任何人都可以很好地解释这种情况是如何发生的并推荐一种解决方法吗？
_{我怀疑 DELETE 语句导致 DEXTable 的 PK 争用需要经常重建。}

如果没有，我应该启用哪些额外的跟踪来深入挖掘死锁的原因？（我想在这里学习）

-- Table definition
CREATE TABLE [dbo].[DEXTable](
                [ExportID] [int] NOT NULL,
                [RespondentID] [int] NOT NULL,
                [Exported] [datetime] NOT NULL,
CONSTRAINT [PK_DEXTable] PRIMARY KEY CLUSTERED …