如果我不在事务中执行查询,我能成为死锁受害者吗?

不

要发生死锁,死锁链中的所有参与者必须 等待 对于资源(锁)。如果您的连接处于空闲状态,这意味着它不执行请求,这意味着它不能等待。

至于其他可能导致你的疗程死亡的情况,我至少可以想到三种:

• 与回滚一起使用的管理操作
• 镜像故障转移
• 故意的 KILL <yourspid> 可能是你的友好DBA开的玩笑

回答你的问题:你 可以 如果您没有在事务中执行查询,请成为死锁牺牲品。

这是违反直觉的,但是你可以通过运行一个 SELECT 语句。

如果运行的查询使用索引,则可能发生这种情况:

• 扫描索引以查找匹配的行

• 其他进程开始更新数据页

• 现在要从匹配行中的数据页提取数据

  在数据页上保持锁的其他进程

  等待数据页锁定释放

• 其他进程已完成更新数据页,希望更新索引

  您持有索引的读取锁

  其他进程等待释放索引锁

• 死锁

所以,严格来说,你 可以 当您不在事务中执行查询时,成为死锁牺牲品。另一个人没有执行他的 UPDATE 一个事务中的语句。

没有人明确使用事务,但存在死锁。

可能的问题:

1. SQL Server只有有限数量的锁。锁可能会用完。

2. 其他资源是有限的(例如内存、tempdb)。持有这些资源可能会导致这些资源耗尽。

3. 事务日志-如果事务处于打开状态,则无法释放逻辑事务日志以供重新使用。结果可能是一个日志被填满。这个问题可能会停止您的进程,因为它会停止整个实例。

考虑:

1. 级联:删除命令中只能有一个表,但级联关系可能接触到其他表。

2. 触发器:修改后的表上的触发器可能会影响其他表。

3. 删除和更新命令可以使用与其他表相接触的FROM子句。我从没见过这个,但我不排除。

交易可能会超时,这就是正在发生的事情。

由于至少取出了一个(或多个)更新锁,并设置了一些读取和表扫描锁,因此可能会杀死您以帮助释放由 其他 交易。SQL Server中的死锁恢复代码不太可能完全没有bug,而且 长时间保持交易不正常 在SQL Server上。但我不希望这种情况经常发生。

有些系统在分离死锁类型问题时,只需开始杀掉未完成匹配工作的__long lived_事务,以释放锁。仅仅因为您不是死锁循环的一部分,就不会停止系统对您的选择。

了解发生了什么事 你的情况 ,您必须使用 SQL Server探查器 收集所有与锁定和死锁相关的事件,以及有关已中止的连接和事务等的事件。很好的缺乏这将需要一段时间,并且对您正在查看的探查器事件有很好的了解…

这类事情的细节在数据库供应商和他们的数据库版本之间是不同的。然而,由于大多数数据库供应商认为事务长时间开放是一种糟糕的设计,因此这样做往往会导致问题,并影响到没有进行最多测试的代码路径。

仅仅因为你没有参与交易并不意味着你没有持有锁。