喜請參見上面image.I僵局圖形部分有兩筆交易是更新同一個表，其中一個是長事務是更新表（同一行）的5倍，但另一個事務只更新該表一次，並且是一個兩個數據庫命中的小事務。從邏輯上看，死鎖圖中的事實都是事務在不同行上具有X鎖並試圖獲得U鎖。我不明白爲什麼較短的事務獲得X鎖，儘管它尚未觸發更新查詢（因爲它是導致死鎖的更新查詢，這意味着它尚未被觸發）。任何幫助將非常可愛。 1）我正在使用隔離級別提交 2）我不能理解第二個/第一個事務可以如何獲得X鎖定，而另一個事務已經在某一行獲得了它。我讀到更新查詢第一個U鎖應用，然後被升級爲X鎖，用於該特定更新的行。現在，當一個事務具有X鎖，那麼另一個事務如何在表掃描期間具有U鎖（以確定要更新的行），它不能讀取具有X鎖的行其他事務。3）這兩個事務都更新同一個表的不同行。任何可能的解決方案都在DB級別上，而不會改變隔離級別。
我無法理解的第二/第一筆交易如何才能獲得X鎖 而其他交易已經得到了它的一些行。
這是數據庫及其性能背後的魔力。鎖可以在不同級別上發佈，如果第二個事務沒有使用表掃描，它可以發出X鎖而不會與第一個事務衝突。在使用索引和表掃描進行搜索的情況下，更新記錄可能沒有發生，因此表中可能存在多個併發X鎖。
我讀過，在更新查詢第一個U鎖被應用，然後是 升級到特定更新行的X鎖。
否更新應直接在記錄上使用X鎖。你的讀取查詢必須強制讀取要讀取的數據（這是@Marc在他的評論中提到的）。正如你所知，EF不支持這個，因爲它不能使用提示。
非常感謝這些都是非常有用的建議。 yes iam不使用任何UPDLOCK提示。並且當我通過使用select * from sys.dm_tran_Locks看到鎖列表時，應用的鎖僅在關鍵級別爲X，在頁級別爲IX，但爲什麼在Deadlock圖中顯示事務正在等待把U鎖。 – ethicallogics
這是你必須在執行的命令中找到的東西。死鎖圖也應該顯示。 –
將IX鎖應用於更新表X鎖KeyLock應用於sys.sysconvgroup後，sys.sysdesend – ethicallogics
這裏的經典答案是：以相同的順序取鎖;這可能涉及發出一個選擇，也許與UPDLOCK。不知道這是可能的與EF雖然。 –
使用SQL事件探查器查看事務期間執行的命令。 –
是的我正在使用EF和它不可能使用鎖提示，除非我們通過ExecuteStoreCommand @Marc發送查詢。 – ethicallogics