Database 什么是数据库中的死锁？

什么是SQL Server中的死锁？死锁何时出现

---

死锁有哪些问题？如何解决

死锁是当两个人需要多个资源来执行时发生的情况，其中一些资源被每个人锁定。这导致了一个事实，即没有B拥有的东西A无法执行，反之亦然

假设我有人A和人B。他们都需要得到两行来运行（第1行和第2行）

• 人员A锁定第1行并尝试获取第2行
• 人员B锁定第2行并尝试获取第1行

人员A无法运行，因为它需要第2行；人员B无法运行，因为它需要第1行。两个人都无法执行，因为他们锁定了对方需要的东西，反之亦然

---

---

减少死锁的一个相当简单的方法是，在所有复杂的事务中，应该按照相同的顺序执行操作。换句话说，按相同的顺序访问表1，然后访问表2。这将有助于减少发生的死锁数量

通常，死锁意味着两个或多个实体正在阻塞某些源，并且没有一个能够完成，因为它们以循环方式阻塞源

举一个例子：假设我有表A和表B，我需要在A和B中进行一些更新，然后我决定在使用时锁定这两个表（这确实是愚蠢的行为，但现在起作用了）。在同一时刻，其他人以相反的顺序做同样的事情-先锁B，然后锁A

按时间顺序，这种情况会发生：

程序1：锁定A

程序2：锁B

proc1:锁定B-开始等待，直到proc2释放B

proc2:Lock A-开始等待，直到proc1释放A

他们两个都完不成。这是一个僵局。在实践中，这通常会导致超时错误，因为不希望任何查询永远挂起，并且底层系统（例如数据库）将终止未及时完成的查询

---

一个现实世界中的死锁例子是，当你把家里的钥匙锁在车里，而车钥匙锁在家里。

当两个（或多个）交易同时发生时，可能会导致僵局 等待释放另一方持有的锁。

什么是死锁 当两个并发事务由于各自等待另一个释放锁而无法进行时，就会发生死锁，如下图所示

因为两个事务都处于锁获取阶段，所以在获取下一个锁之前，两个事务都不会释放锁

从僵局中恢复过来 如果您使用的是依赖于锁的并发控制算法，那么总是存在在死锁情况下运行的风险。死锁可以发生在任何并发环境中，而不仅仅是在数据库系统中

例如，如果两个或多个线程正在等待先前获取的锁，因此没有线程可以取得任何进展，则多线程程序可能会死锁。如果在Java应用程序中发生这种情况，JVM不能强制线程停止执行并释放锁

即使

Thread

类公开了一个方法，该方法自Java 1.1以来一直被弃用，因为它会导致线程停止后对象处于不一致的状态。相反，Java定义了一个

interrupt

方法，该方法充当一个提示，因为被中断的线程可以忽略中断并继续执行

因此，Java应用程序无法从死锁情况中恢复，应用程序开发人员有责任以永远不会发生死锁的方式对锁获取请求进行排序

但是，数据库系统无法强制执行给定的锁获取命令，因为无法预见某个事务将进一步获取哪些其他锁。保存锁顺序成为数据访问层的责任，数据库只能帮助从死锁情况中恢复

数据库引擎运行一个单独的进程，扫描当前冲突图中的锁等待周期（由死锁引起）。 当检测到一个循环时，数据库引擎将选取一个事务并中止它，从而释放其锁，以便另一个事务可以进行

与JVM不同，数据库事务被设计为原子工作单元。因此，回滚会使数据库保持一致状态

死锁优先级 当数据库选择回滚被卡住的两个事务中的一个时，并不总是能够预测哪个事务将被回滚。根据经验，数据库可能会选择以较低的回滚成本回滚事务

神谕 根据，检测到死锁的事务是其语句将回滚的事务

SQL Server SQL Server允许您通过会话变量控制在死锁情况下哪个事务更有可能回滚

DEADLOCK\u PRIORITY

会话可以接受-10到10之间的任何整数，或者预定义的值，例如

LOW（-5）

、

NORMAL（0）

或

HIGH（5）

如果出现死锁，当前事务将回滚，除非其他事务具有较低的死锁优先级值。如果两个事务具有相同的优先级值，则SQL Server将以最小的回滚成本回滚该事务

PostgreSQL 如中所述，PostgreSQL不保证回滚哪个事务

MySQL

---

MySQL试图这样做，因为释放更少的锁成本更低。

@Pz，我怀疑NOLOCK提示是否会写入数据磁盘？我的意思是，它会提交事务还是强制放弃事务以允许访问anathor？Nolock正是这样做的-它确保查询不会生成锁。P