mysql解决死锁问题

官方定义如下：两个事务都持有对方需要的锁，并且在等待对方释放，并且双方都不会释放自己的锁。

这个就好比你有一个人质，对方有一个人质，你们俩去谈判说换人。你让对面放人，对面让你放人。

看到这里，也许你会有这样的疑问，事务和谈判不一样，为什么事务不能使用完锁之后立马释放呢？居然还要 *** 作完了之后一直持有锁？这就涉及到 MySQL 的并发控制了。

MySQL的并发控制有两种方式，一个是 MVCC，一个是两阶段锁协议。那么为什么要并发控制呢？是因为多个用户同时 *** 作 MySQL 的时候，为了提高并发性能并且要求如同多个用户的请求过来之后如同串行执行的一样（ 可串行化调度 ）。具体的并发控制这里不再展开。咱们继续深入讨论两阶段锁协议。

官方定义：

对应到 MySQL 上分为两个阶段：

就是说呢，只有遵循两段锁协议，才能实现 可串行化调度 。

但是两阶段锁协议不要求事务必须一次将所有需要使用的数据加锁，并且在加锁阶段没有顺序要求，所以这种并发控制方式会形成死锁。

MySQL有两种死锁处理方式：

由于性能原因，一般都是使用死锁检测来进行处理死锁。

死锁检测的原理是构建一个以事务为顶点、锁为边的有向图，判断有向图是否存在环，存在即有死锁。

检测到死锁之后，选择插入更新或者删除的行数最少的事务回滚，基于 INFORMATION_SCHEMAINNODB_TRX 表中的 trx_weight 字段来判断。

MySQL如何处理死锁

我理解的是：读表的锁表是指在读的过程中上锁，不允许中途还insert其他记录，当读表完毕，获得select结果后，表就解锁了，可以继续新的select或insert等 *** 作。

例子里：2人同时借钱，没有业务锁的话，两个请求发到后端后可能同时去select，此时2次借款 *** 作select余额都是1000（在另一人借200后回写余额800之前），于是2个请求 *** 作各自开始借钱，算出借钱后都剩下800，再分别update进表中，表里余额就是800

如果加业务锁：2个请求到后端后，select余额和借钱后Update按一个事务进行，那第1人select 1000元并借款后剩下800更新进表中，完成第1人借钱事务后，再进行第2人借钱select 剩下的800元并借款后剩下600更新进表中，就可以避免

事务锁是为了应对并发问题的一种解决机制，在事务获取数据块当前状态的依赖关系（如通过读取或修改数据）之前，它必须保护自己不受其他事务对同一数据进行修改的影响，事务通过请求锁定数据块来达到此目的。

1锁模式如果某个事务已获得特定数据的锁，则其他事务不能获得与该锁模式发生冲突的锁。如果事务请求的锁模式与已授予同一数据的锁发生冲突，则数据库引擎实例将暂停事务请求直到第一个锁被释放。锁有多种模式，包括共享锁、更新锁、排他锁等。

（1)共享锁（S锁）共享锁允许并发事务在封闭式并发事务下读取资源。有关详细信息，请参阅“213并发事务”的类型。资源上存在共享锁时，任何其他事务都不能修改数据。读取 *** 作一完成，就立即释放资源上的共享锁，除非将事务隔离级别设置为可重复读或更高级别，或者在事务持续时间内用锁定提示保留共享锁。

2）更新锁（U锁）更新锁是共享锁和排他锁的混合型锁，更新锁意味着在做一个更新时，一个共享锁在扫描完成符合条件的数据后可能会转化成排他锁。这里面有两个步骤：（（1)扫描获取Where条件时，这部分是一个更新查询，此时是一个更新锁。

（2）如果将执行写入更新，此时该锁升级到排他锁；否则，该锁转变成共享锁。

3）排他锁（X锁）排他锁可以防止并发事务对资源进行访问，不与其他任何锁兼容。使用排他锁时，任何其他事务都无法修改数据；仅在未提交读隔离级别时才会被其他事务读取占有的数据资源。

2死锁死锁是指两个或两个以上的进程在执行过程中，由于竞争资源或者彼此通信而造成的一种阻塞的现象，若无外力作用，它们将无法推进下去，此时称系统处于死锁状态或系统产生了死锁。这些永远在互相等待的进程称为死锁进程。下面从死锁产生的原因、条件及预防措施等方面来研究事务的死锁。

（1)死锁产生的原因当两个或多个进程各自具有某个资源的锁定，但其他进程尝试要锁定此资源，而造成进程永久封锁彼此时，会发生死锁。例如，事务A取得数据列1的排他锁定，事务B取得数据列2的排他锁定，事务A现在要求取得数据列2的独占锁定，事务B现在要求取得数据列1的独占锁定。事务A与事务B均需要独占数据列1与数据列2的资源，但两个资源分别被两个事务各占一个，互相等待对方的占据的资源才能完成本身的事务，就会造成事务间进程的死锁。

2）死锁产生的条件虽然进程在运行过程中可能发生死锁，但死锁的发生也必须具备一定的条件。死锁的发生必须具备以下四个必要条件。

（（1)互斥条件。互斥条件指进程对所分配到的资源进行排他性使用，即在一段时间内某资源只由一个进程占用。如果此时还有其他进程请求资源，则请求者只能等待，直至占有资源的进程用完释放。

（2）请求和保持条件。请求和保持条件指进程已经保持至少一个资源，但又提出了新的资源请求，而该资源已被其他进程占有，此时请求进程阻塞，但又对自己已获得的其他资源保持不放。

（3）不剥夺条件。不剥夺条件指进程已获得的资源在未使用完之前不能被剥夺，只能在使用完时由自己释放。

（4）环路等待条件。环路等待条件指在发生死锁时，必然存在一个进程——资源的环形链，即进程集合{P0，P1，P2，…，Pn}中的P0正在等待一个P1占用的资源；P1正在等待P2占用的资源；…；Pn正在等待已被P0占用的资源。死锁的预防措施理解了死锁的原因，尤其是产生死锁的四个必要条件，就可以最大可能地避免、预防和解除死锁。只要打破四个必要条件之一就能有效预防死锁的发生。

（（1)打破互斥条件。改造独占性资源为虚拟资源，但大部分资源已无法改造。

（2）打破不可抢占条件。当一进程占有一独占性资源后又去申请另一独占性资源而无法满足时，则退出原占有的资源。

（3）打破占有且申请条件。采用资源预先分配策略，即进程运行前申请全部资源，满足则运行，不满足就等待，这样就不会出现占有部分资源后再去申请其他资源的场景。

（4）打破循环等待条件。实现资源有序分配策略，对所有设备实现分类编号，所有进程只能采用按序号递增的形式申请资源。

所以，在系统设计、进程调度等方面要注意如何不让这四个必要条件成立，如何确定资源的合理分配算法，避免进程永久占据系统资源。此外，也要防止进程在处于等待状态的情况下占用资源，在系统运行过程中，对进程发出的每一个系统能够满足的资源申请进行动态检查，并根据检查结果决定是否分配资源，若分配后系统可能发生死锁，则不予分配；否则予以分配。因此，对资源的分配要给予合理的规划。

以上就是关于mysql解决死锁问题全部的内容，包括:mysql解决死锁问题、看了一下，MYSQL在读写时会自动给表或者行加锁，那为什么还会出现所谓的并发问题、事务锁与并发问题是什么关系等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！