Question

所以，我一直在研究使用其中一些SQL服务器管理工具，我很惊讶发现简单的选择阻塞自己并造成死锁。我做了一些研究，但我真的很惊讶这可能发生。任何人都可以澄清或者解决为什么会发生这种情况吗？

我说的是一个简单的选择。

 SELECT
     ID
 FROM   
     MainTable
 WHERE 
     Name Like 'John Smith'

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

Answer 1

在SQL 2000中，进程有时会报告为阻塞，但我认为这不适用于SQL Server的更高版本。

latch waits reported as blocking

SELECT语句肯定可能导致死锁，因为在选择数据时会获取共享锁，但是还必须有另一个尝试更新数据的进程。

Answer 2

并行执行计划可以显示为阻止自身的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;

Answer 3

这个简单的选择本身不会死锁，唯一可能的原因是在你阅读时更新/删除行。尝试启动SQL Server Profiler并使用：

死锁
死锁链
deadloch graph

模板中的事件。特别是死锁图将帮助您确定导致死锁的两个进程和被选为死锁的受害者

基本选择死锁本身

3 个答案: