Sql DB中是否可能存在锁的连锁反应？

也许我误解了表锁的本质，但我想知道是否有可能在某些表上产生锁的连锁反应

我不知道DB范围有多大，但是考虑200个DB表和数百个/数千个存储过程。 如果在某个点上，一个过程正在锁定一个表，因此另一个过程遇到了锁，但由于第一个锁，它以某种方式成功地锁定了另一个表，并且这一过程不断重复，直到所有过程在某个无限链中相互阻塞为止

所以我们到处都会得到锁和超时，直到调用这些过程的所有服务都停止并重新启动，并修复了初始过程的根本原因

---

这种情况在任何情况下都可能发生吗？

死锁可能适合您所描述的内容，是的，它们可能发生。这就是为什么开发人员应该注意查询和事务，而不是使用长事务或全局连接。ADO.NET和EF、EF Core、NHibernate都是为在没有持续打开的连接的情况下工作而构建的，因此这种锁爆炸不会发生——除非有人在每个服务运行时运行表碎片整理。糟糕的编码实践，如使用

NOLOCK

来掩盖并发问题，也会在表级别使用更多的锁，这会导致所有内容冻结，即使每个表只修改了几行。例如

如果某个过程在某一点上锁定了一个表

存储过程为什么要这样做，除非是维护存储过程？@TimBiegeleisen没错！我将lock和deadlock引用为同一术语，我不知道deadlock是等待另一个的对象。所以死锁肯定会触发另一个，对吗？@PanagiotisKanavos insert and update do lock rows，不是吗？因此，如果一些并行服务使用相同的过程，那么它们应该总是使用不同的资源，这是肯定的。但是，如果其中一个服务最终在其工作中失败并产生锁，从而影响请求相同表的其他服务，则会发生死锁