锐客网

  1. 首页 > 睿知 > it技术 > >

mysql怎么解决死锁 mysql死锁解决方案

IT技术死锁

解决死锁的4种基本方法解除死锁的方法有：
1、资源剥夺
产生死锁的条件之一就是：资源不可剥夺 。如果允许进程可以剥夺其他进程的资源，那么就可以使得一个进程可以从其他进程剥夺足够的资源，从而解除死锁状态 。
2、撤销进程
按照某种顺序，撤销进程并释放资源，直到释放出足够多的资源，并解除死锁 。最极端的情况就是 ， 撤销了所有进程 。
3、进程回退
让进程回退到某个状态（回退到没有获取某种资源的状态），从而释放已经获得的资源，这样其他进程就可以获得因回退而被释放的资源并解除死锁状态 。
4、鸵鸟策略
假装没有发生死锁，不管了 。因为解除死锁的代价非常高，所以就忽略死锁 。死锁产生的本质原因就是那两个，但因为死锁已经发生了，所以只能从资源这一方向入手了 。
解决一次mysql死锁问题 多线程开启事务处理 。每个事务有多个update操作和一个insert操作（都在同一张表） 。
默认隔离级别：Repeatable Read
只有hotel_id=2和hotel_id=11111的数据
逻辑删除原有数据
插入新的数据
根据现有数据情况，update的时候没有数据被更新
【mysql怎么解决死锁 mysql死锁解决方案】 报了非常多一样的错
发现居然有死锁 。
根据常识考虑，我每个线程（事务）更新的数据都不冲突，为什么会产生死锁？
带着这个问题，打印mysql最近一次的死锁信息
show engine innodb status
显示如下
发现事务1在等待一个锁
事务2也在等待一个锁
而且事物2持有了事物1需要的锁
关于锁的描述，出现了 lock_mode，gap before rec ，insert intention 等字眼 ， 看不懂说明了什么？说明我关于mysql的锁相关的知识储备还不够 。那就开始调查mysql的锁相关知识 。
通过搜索引擎，
锁的持有兼容程度如下表
那么再回到死锁日志，可以知道 :
事务1正在获取插入意向锁
事务2正在获取插入意向锁，持有排他gap锁
再看我们上面的锁兼容表格，可以知道，gap lock和insert intention lock是不兼容的
那么就可以推断出： 事务1持有gap lock ， 等待事务2的insert intention lock释放；事务2持有gap lock，等待事务1的insert intention lock释放，从而导致死锁 。
那么新的问题就来了，事务1的intention lock 为什么会和事务2的gap lock 有交集，或者说，事务1要插入的数据的位置为什么会被事务2给锁?。?
让我回顾一下gap lock的定义：
间隙锁 ， 锁定一个范围，但不包括记录本身 。GAP锁的目的，是为了防止同一事务的两次当前读，出现幻读的情况
那为什么是gap lock ， gap lock到底是基于什么逻辑锁的记录？发现自己相关的知识储备还不够 。那就开始调查 。
调查后发现，当当前索引是一个 普通索引 的时候，会加一个gap lock来防止幻读，此gap lock 会锁住一个左开右闭的区间 。假设索引为xx_idx（xx_id） ， 数据分布为1,4,6,8,12，当更新xx_id=9的时候，这个时候gap lock的锁定记录区间就是(8，12] ， 也就是锁住了xxid in (9,10,11,12)的数据 ， 当有其他事务要插入xxid in (9,10,11,12)的数据时 ， 就会处于等待获取锁的状态 。
ps：当前索引不是普通索引，而且是唯一索引等其他情况，请参考下面资料
MySQL 加锁处理分析
回到我自己的案例中，重新屡一下事务1的执行过程：
因为普通索引
KEY hotel_date_idx ( hotel_id , rate_date )
的关系 这段sql会获取一个gap lock，范围(2,11111]
这段sql会获取一个insert intention lock （waiting）
再看事务2的执行过程
因为普通索引
KEY hotel_date_idx ( hotel_id , rate_date )
的关系 这段sql也会获取一个gap lock，范围也是(2,11111]（根据前面的知识，gap lock之间会互相兼容，可以一起持有锁的）
这段sql也会获取一个insert intention lock （waiting）
看到这里 ， 基本也就破案了 。因为普通索引的关系，事务1和事务2的gap lock的覆盖范围太广，导致其他事务无法插入数据 。
重新梳理一下：
所以从结果来看，一堆事务被回滚 ， 只有10007数据被更新成功
gap lock 导致了并发处理的死锁
在mysql默认的事务隔离级别（repeatable read）下，无法避免这种情况 。只能把并发处理改成同步处理 。或者从业务层面做处理 。
共享锁、排他锁、意向共享、意向排他
record lock、gap lock、next key lock、insert intention lock
show engine innodb status
详解MySQL（InnoDB）如何处理死锁 锁是需要事务结束后才释放的 。
一个是 MVCC，一个是两阶段锁协议 。
为什么要并发控制呢？是因为多个用户同时操作 MySQL 的时候 ， 为了提高并发性能并且要求如同多个用户的请求过来之后如同串行执行的一样（为了解决脏读、不可重复读、幻读）
官方定义：
两阶段锁协议是指所有事务必须分两个阶段对数据加锁和解锁，在对任何数据进行读、写操作之前 ， 事务首先要获得对该数据的封锁；在释放一个封锁之后，事务不再申请和获得任何其他封锁 。
对应到 MySQL 上分为两个阶段：
但是两阶段锁协议不要求事务必须一次将所有需要使用的数据加锁（innodb在需要的索引列数据才锁行），并且在加锁阶段没有顺序要求，所以这种并发控制方式会形成死锁 。
MySQL有两种死锁处理方式：
死锁检测 （默认开启）
死锁检测的原理是构建一个以事务为顶点、锁为边的有向图，判断有向图是否存在环，存在即有死锁 。
回滚
检测到死锁之后，选择插入更新或者删除的行数最少的事务回滚 ， 基于 INFORMATION_SCHEMA.INNODB_TRX 表中的 trx_weight 字段来判断 。
收集死锁信息：
减少死锁：
死锁解决：
死锁怎么解决？处理死锁的思路如下：
预防死锁：破坏四个必要条件中的一个或多个来预防死锁 。
避免死锁：在资源动态分配的过程中，用某种方式防止系统进入不安全的状态 。
检测死锁：运行时产生死锁，及时发现思索，将程序解脱出来 。
解除死锁：发生死锁后，撤销进程，回收资源，分配给正在阻塞状态的进程 。
预防死锁的办法：
破坏请求和保持条件：
1、一次性的申请所有资源 。之后不在申请资源，如果不满足资源条件则得不到资源分配 。
2、只获得初期资源运行，之后将运行完的资源释放，请求新的资源 。
破坏不可抢占条件：当一个进程获得某种不可抢占资源，提出新的资源申请，若不能满足 ， 则释放所有资源，以后需要，再次重新申请 。
破坏循环等待条件：对资源进行排号，按照序号递增的顺序请求资源 。若进程获得序号高的资源想要获取序号低的资源，就需要先释放序号高的资源 。
扩展资料
形成死锁的四个必要条件：
（1） 互斥条件：一个资源每次只能被一个进程使用 。
（2） 请求与保持条件：一个进程因请求资源而阻塞时，对已获得的资源保持不放 。
（3） 不剥夺条件:进程已获得的资源 ， 在末使用完之前，不能强行剥夺 。
（4） 循环等待条件:若干进程之间形成一种头尾相接的循环等待资源关系 。
如果一组进程中每一个进程都在等待仅由该组进程中的其他进程才能引发的事件，那么该组进程是死锁的 。
举例来说：有两个进程A和B,A持有资源a等待b资源，B持有资源b等待a资源，两个进程都在等待另一个资源的同时不释放资源，就形成死锁 。
关于mysql怎么解决死锁和mysql死锁解决方案的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站 。

    推荐阅读


    上一篇：linuxiostat命令详解的简单介绍

    下一篇：java高级应用代码，java高级编程题库和答案