基本的選擇死鎖本身

所以，我一直在研究更多的SQL服務器管理工具，使用其中的一些，我驚訝地發現簡單的選擇阻止自己並導致死鎖。我做了一些研究，但我真的很驚訝這可能發生。任何人都可以澄清，或者可以解決，爲什麼發生這種情況？基本的選擇死鎖本身

我正在談論一個簡單的選擇。

SELECT 
    ID 
FROM 
    MainTable 
WHERE 
    Name Like 'John Smith'

使用Microsoft SQL Server Managment Studios，如果它很重要。

來源

2014-10-02 DidIReallyWriteThat

你怎麼知道它是死鎖本身？你能描述一下你實際看到的是什麼嗎？ – Blorgbeard 2014-10-02 21:42:12

這不會導致自己的死鎖。 – 2014-10-02 21:43:04

如果您在選擇數據的同時插入數據庫，則可能會將您的查詢選爲死鎖受害者。如果你不關心剛剛插入的數據，你可以在你的表名後添加'nolock'，它會做一個「髒」的讀取，並且不會發生死鎖。 – paqogomez 2014-10-02 21:51:09

在SQL 2000進程有時會報告阻塞自己，但我不認爲這適用於更高版本的SQL Server。

latch waits reported as blocking

這絕對是可能的SELECT語句導致死鎖，因爲在選擇數據時，共享鎖被收購，但也必須是試圖更新該數據的另一過程。

來源

2014-10-02 22:19:13 jazza1000

實際上，共享鎖（除非我們處於可重複讀取隔離級別或更糟糕的事務中）只會持續一小段時間，然後突然釋放，至少在單行或鍵上。 – Antonio 2017-05-18 12:38:57

並行執行計劃可以顯示爲自己的SPID阻塞。這基本上只是等待查詢中其他任務完成的線程。死鎖是另一個問題，由不同的會議彼此等待引起。死鎖（和過度的並行）可能是需要查詢和索引調整的一個症狀。

如果您正在運行SQL 2008或更高版本，默認情況下system_helath擴展事件跟蹤會捕獲死鎖信息。以下是從環形緩衝區中提取最近死鎖信息的查詢。這將消除一些猜測。

SELECT 
     xed.value('@timestamp', 'datetime') as Creation_Date, 
     xed.query('.') AS Extend_Event 
FROM 
(
     SELECT CAST([target_data] AS XML) AS Target_Data 
     FROM sys.dm_xe_session_targets AS xt 
     INNER JOIN sys.dm_xe_sessions AS xs 
     ON xs.address = xt.event_session_address 
     WHERE xs.name = N'system_health' 
     AND xt.target_name = N'ring_buffer' 
) AS XML_Data 
CROSS APPLY Target_Data.nodes('RingBufferTarget/event[@name="xml_deadlock_report"]') AS XEventData(xed) 
ORDER BY Creation_Date DESC;

來源

2014-10-03 01:51:23

這個簡單的選擇本身不能死鎖，唯一可能的原因是別的是在讀取時更新/刪除行。嘗試啓動SQL Server設置和使用：

僵局
僵局鏈
deadloch圖

在模板中的事件。特別是死鎖圖將幫助您識別哪兩個進程導致trhe死鎖，並選擇一個作爲死鎖受害者

來源

2017-05-18 12:36:36 Antonio

基本的選擇死鎖本身

回答

相關問題