Sql 非常神秘的僵局

我在网上读了大量关于死锁的信息，以确保我没有问一个愚蠢的问题。发生死锁的下表用作订单队列。没有记录被实际删除，只有它们的状态更改，即处理、取消、完成。 我观察到这张桌子上有UPDLOCK的SELECTs上出现了神秘的死锁。我看到的关于SELECT的唯一特点是，有一个没有UPDLOCK的内部SELECT，但这不重要。该表已启用行锁定。这些选择由单独的作业调度程序并行运行。这种选择的含义是，它检索具有一个或多个指定状态的第一个最早订单，即上述处理、取消、完成。具有最小ID的订单-手动选择最小ID，在下面的查询中，其为6850000被视为第一个订单。这样做是出于性能原因。下面是一个实际选择：

select * from TORDERSUMMARY with (updlock, rowlock) 
where ID in 
(select min(ID) from TORDERSUMMARY 
 where ID > 6850000  and (ORDERSTATUS in ( 'INITIATED' )) 
 and (ORDERDISPATCHSTATUS in ( 0  ,  2  ,  4 )) and (ORDERGROUPID is null))

表中的主键ID上定义了聚集索引。正如SQLServerManagementStudio 2008所给出的，此类查询的估计和实际执行计划是聚集索引搜索。表上有许多非聚集索引，我希望NC索引操作与聚集索引操作会发生死锁。我在网上详细阅读了许多此类情况，但由于只有聚集索引是以索引查找的最佳方式使用的，所以原因似乎不在那里

内部SELECT没有UPDLOCK、ROWLOCK提示，因此不会使用锁定选择多个记录。我无法想象任何情况下，两个这样的选择会陷入僵局。当然，UPDLOCK提示是因为代码随后会尝试更新订单的状态以将其标记为已处理，等等

---

下面是SQLServerManagementStudio 2008中的一个死锁XDL文件-。服务器本身是9.0.4035。SQL查询很长，因此出于某种原因，它们在XDL文件中被截断，但选择肯定是上述类型的，因为我已经用这种选择对服务器进行了手动压力测试，死锁似乎以同样的方式随机发生。

规则1：不要在人工键上建立聚集索引；在自然键上建立聚集索引，并为人工键建立非聚集索引。

从技术上讲，这是一种观点，而不是一种规则：。有一些非常好的理由可以在自然键上构建聚集索引，但也有一些同样好的理由可以在人工键上构建聚集索引。