这个阻塞是由于缺少分号来分隔批次吗?

Question

希望减少阻塞，在运行Pinal Dave的阻塞脚本时，我看到了以下内容:

虚拟表名示例

BLOCKING_TREE
HEAD -  62 drop table if exists live.dbo.connection  select * into live.dbo.connection from [dbo].connection_temp
|         |------  137 SELECT tr.name AS [Name], tr.object_id AS [ID] FROM sys.triggers AS tr WHERE (tr.parent_class = 0) ORDER BY [Name] ASC

这可能是由于在INSERT期间对SPID 62上的DROP语句所做的触发检查仍然保持，从而阻塞了正在寻找返回TR信息的SPID 137吗?如果是，在DROP和INSERT之间添加分号会释放锁吗?

由于这种情况发生在许多脚本中，但在我看到完全相同的SP作为阻塞树的头部之前可能需要很长时间，因此我正在寻找关于我的思路是否正确的建议，或者我是否可能浪费时间在数百个遗留/继承的SP中填充分号以试图减少阻塞。

Answer 1

简短回答-否

较长的答案-分号目前(大多数情况下)在T-SQL中是可选的。如果它们的存在或不存在会影响阻塞行为，则表明所采用的锁(或它们的作用域)会受到不同的影响。这属于"非凡的主张需要非凡的证据"的范畴。

---

也就是说，如果您在触发器上下文中删除/创建活动表(我看到drop table if exists...,select * into...)，我强烈希望存在并发问题。我建议要么切换到临时表，要么停止删除/创建表，而是将数据从一个staging表插入到活动表中。但是在没有看到触发器定义的情况下，很难确定。