基本的选择死锁本身

所以，我一直在研究更多的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

基本的选择死锁本身

回答

相关问题