このクエリがデッドロックを引き起こすのはなぜですか？

このクエリがデッドロックを引き起こすのはなぜですか？

UPDATE TOP(1) system_Queue SET
  [StatusID] = 2,
  @ID = InternalID
WHERE InternalID IN (
    SELECT TOP 1 
      InternalID FROM system_Queue
    WHERE IsOutGoing = @IsOutGoing AND StatusID = 1
ORDER BY MessageID ASC, InternalID ASC)

追加されたデッドロックグラフ：

<keylock hobtid="72057594236436480" dbid="9" objectname="Z.dbo.system_Queue" indexname="PK_system_Queue" id="lock5b25cc80" mode="X" associatedObjectId="72057594236436480">
    <owner-list>
     <owner id="processc6fe40" mode="X"/>
    </owner-list>
    <waiter-list>
     <waiter id="processc7b8e8" mode="S" requestType="wait"/>
    </waiter-list>
   </keylock>
   <keylock hobtid="72057594405453824" dbid="9" objectname="Z.dbo.system_Queue" indexname="IX_system_Queue_DirectionByStatus" id="lock48cf3180" mode="S" associatedObjectId="72057594405453824">
    <owner-list>
     <owner id="processc7b8e8" mode="S"/>
    </owner-list>
    <waiter-list>
     <waiter id="processc6fe40" mode="X" requestType="wait"/>
    </waiter-list>
   </keylock>

追加：

このタイプのデッドロックを回避する方法を説明した記事を提供してくれたSankarに感謝します。

• 読者の投影から不要な列を削除するので、クラスター化インデックスを検索する必要がありません。
• 必要な列を含まれる列として非クラスター化インデックスに追加して、インデックスがカバーされるようにして、リーダーがクラスター化インデックスを検索しないようにします。
• 非クラスター化インデックスを維持する必要がある更新を回避する

同じステートメントで同じテーブルに対してSELECTとUPDATEを実行しようとしているように見えます。

SELECTはIX_system_Queue_DirectionByStatusインデックス内の値に共有ロックを保持しており、UPDATEはそれらのロックを解放してから、主キーを更新する排他的ロックを取得する必要があります（これはクラスター化されており、 IX_system_Queue_DirectionByStatusキー値）。

とにかく、私のクエリは、このクエリは、選択して更新しているインデックス値が競合していないというまれな機会でのみ成功すると思います。あなたが実行するたびにデッドロックしていますか？

デッドロックについて詳しく説明しているリンクは次のとおりです。http：//sqlblog.com/blogs/jonathan_kehayias/archive/2008/07/30/the-anatomy-of-a-deadlock.aspx

この投稿に回答のマークを付けることは期待していませんが、このトピックに関する他のSQL Serverエキスパートがここで詳細情報を共有しています。

http://sqlblog.com/blogs/alexander_kuznetsov/archive/2009/01/01/reproducing-deadlocks-involving-only-one-table.aspx

http://rusanu.com/2009/05/16/readwrite-deadlock/