锐客网

  1. 首页 > 生活百科 > it技术 > >

怎么防止mysql死锁 mysql死锁处理方法

死锁IT技术

解决一次mysql死锁问题 多线程开启事务处理 。每个事务有多个update操作和一个insert操作（都在同一张表） 。
默认隔离级别：Repeatable Read
只有hotel_id=2和hotel_id=11111的数据
逻辑删除原有数据
插入新的数据
根据现有数据情况，update的时候没有数据被更新
报了非常多一样的错
发现居然有死锁 。
根据常识考虑，我每个线程（事务）更新的数据都不冲突，为什么会产生死锁？
带着这个问题 ， 打印mysql最近一次的死锁信息
show engine innodb status
显示如下
发现事务1在等待一个锁
事务2也在等待一个锁
而且事物2持有了事物1需要的锁
关于锁的描述，出现了 lock_mode ，gap before rec ，insert intention 等字眼，看不懂说明了什么？说明我关于mysql的锁相关的知识储备还不够 。那就开始调查mysql的锁相关知识 。
通过搜索引擎 ，
锁的持有兼容程度如下表
那么再回到死锁日志，可以知道 :
【怎么防止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解决死锁问题官方定义如下：两个事务都持有对方需要的锁，并且在等待对方释放，并且双方都不会释放自己的锁 。
这个就好比你有一个人质，对方有一个人质，你们俩去谈判说换人 。你让对面放人，对面让你放人 。
看到这里，也许你会有这样的疑问，事务和谈判不一样 ， 为什么事务不能使用完锁之后立马释放呢？居然还要操作完了之后一直持有锁？这就涉及到 MySQL 的并发控制了 。
MySQL的并发控制有两种方式 ， 一个是 MVCC ， 一个是两阶段锁协议 。那么为什么要并发控制呢？是因为多个用户同时操作 MySQL 的时候，为了提高并发性能并且要求如同多个用户的请求过来之后如同串行执行的一样（ 可串行化调度 ） 。具体的并发控制这里不再展开 。咱们继续深入讨论两阶段锁协议 。
官方定义：
对应到 MySQL 上分为两个阶段：
就是说呢 ， 只有遵循两段锁协议，才能实现可串行化调度。
但是两阶段锁协议不要求事务必须一次将所有需要使用的数据加锁，并且在加锁阶段没有顺序要求，所以这种并发控制方式会形成死锁 。
MySQL有两种死锁处理方式：
由于性能原因 ， 一般都是使用死锁检测来进行处理死锁 。
死锁检测的原理是构建一个以事务为顶点、锁为边的有向图 ， 判断有向图是否存在环，存在即有死锁 。
检测到死锁之后，选择插入更新或者删除的行数最少的事务回滚，基于 INFORMATION_SCHEMA.INNODB_TRX 表中的 trx_weight 字段来判断 。
MySQL如何处理死锁
MySQL如何设置避免活锁的先来先服务策略？一、活锁
如果事务T1封锁了数据R，事务T2又请求封锁R，于是T2等待 。T3也请求封锁R，当T1释放了R上的封锁之后系统首先批准了T3的请求，T2仍然等待 。然后T4又请求封锁R，当T3释放了R上的封锁之后系统又批准了T4的请求，...，T2有可能永远等待，这就是活锁的情形，如图8.4(a)所示 。
避免活锁的简单方法是采用先来先服务的策略 。
二、死锁
如果事务T1封锁了数据R1，T2封锁了数据R2，然后T1又请求封锁R2 ， 因T2已封锁了R2，于是T1等待T2释放R2上的锁 。接着T2又申请封锁R1，因T1已封锁了R1，T2也只能等待T1释放R1上的锁 。这样就出现了T1在等待T2，而T2又在等待T1的局面 ， T1和T2两个事务永远不能结束，形成死锁 。
1. 死锁的预防
在数据库中，产生死锁的原因是两个或多个事务都已封锁了一些数据对象，然后又都请求对已为其他事务封锁的数据对象加锁 ， 从而出现死等待 。防止死锁的发生其实就是要破坏产生死锁的条件 。预防死锁通常有两种方法：
① 一次封锁法
一次封锁法要求每个事务必须一次将所有要使用的数据全部加锁，否则就不能继续执行 。
一次封锁法虽然可以有效地防止死锁的发生，但也存在问题，一次就将以后要用到的全部数据加锁，势必扩大了封锁的范围 ， 从而降低了系统的并发度 。
② 顺序封锁法
顺序封锁法是预先对数据对象规定一个封锁顺序，所有事务都按这个顺序实行封锁 。
顺序封锁法可以有效地防止死锁，但也同样存在问题 。事务的封锁请求可以随着事务的执行而动态地决定，很难事先确定每一个事务要封锁哪些对象，因此也就很难按规定的顺序去施加封锁 。
可见 ， 在操作系统中广为采用的预防死锁的策略并不很适合数据库的特点，因此DBMS在解决死锁的问题上普遍采用的是诊断并解除死锁的方法 。
2. 死锁的诊断与解除
① 超时法
如果一个事务的等待时间超过了规定的时限，就认为发生了死锁 。超时法实现简单，但其不足也很明显 。一是有可能误判死锁，事务因为其他原因使等待时间超过时限，系统会误认为发生了死锁 。二是时限若设置得太长 ， 死锁发生后不能及时发现 。
② 等待图法
事务等待图是一个有向图G=(T,U) 。T为结点的集合，每个结点表示正运行的事务；U为边的集合，每条边表示事务等待的情况 。若T1等待T2,则T1、T2之间划一条有向边 ， 从T1指向T2 。事务等待图动态地反映了所有事务的等待情况 。并发控制子系统周期性地（比如每隔1分钟）检测事务等待图，如果发现图中存在回路，则表示系统中出现了死锁 。
DBMS的并发控制子系统一旦检测到系统中存在死锁，就要设法解除 。通常采用的方法是选择一个处理死锁代价最小的事务，将其撤消，释放此事务持有的所有的锁，使其它事务得以继续运行下去 。当然，对撤消的事务所执行的数据修改操作必须加以恢复 。
分布式mysql 怎么防止死锁的数据库系统实现了各种死锁检测和死锁超时机制，越复杂的系统，比如InnoDB存储引擎，越能检测到死锁的循环依赖，并立即返回一个错误 。
详解MySQL（InnoDB）如何处理死锁 锁是需要事务结束后才释放的 。
一个是 MVCC，一个是两阶段锁协议 。
为什么要并发控制呢？是因为多个用户同时操作 MySQL 的时候，为了提高并发性能并且要求如同多个用户的请求过来之后如同串行执行的一样（为了解决脏读、不可重复读、幻读）
官方定义：
两阶段锁协议是指所有事务必须分两个阶段对数据加锁和解锁，在对任何数据进行读、写操作之前，事务首先要获得对该数据的封锁；在释放一个封锁之后 ， 事务不再申请和获得任何其他封锁 。
对应到 MySQL 上分为两个阶段：
但是两阶段锁协议不要求事务必须一次将所有需要使用的数据加锁（innodb在需要的索引列数据才锁行），并且在加锁阶段没有顺序要求 ， 所以这种并发控制方式会形成死锁 。
MySQL有两种死锁处理方式：
死锁检测 （默认开启）
死锁检测的原理是构建一个以事务为顶点、锁为边的有向图，判断有向图是否存在环，存在即有死锁 。
回滚
检测到死锁之后 ， 选择插入更新或者删除的行数最少的事务回滚，基于 INFORMATION_SCHEMA.INNODB_TRX 表中的 trx_weight 字段来判断 。
收集死锁信息：
减少死锁：
死锁解决：
php中如何避免mysql数据库死锁mysql一般不会死锁，除非程序有问题 。性能优先事务不优先的数据库（设置）不要追求可靠性万无一失 。
网站性能问题主要是数据库量大了以后，查询扫描硬盘而产生的 。其它性能不要太在意 。编写代码的时候不要坚持性能原则，而是坚持可用性原则 。初学者编写代码通常容易面向性能，但是一个项目的一个页面几百、几千行代码是很常见的 。要面向可用性、可维护性、可读性 。这是项目原则 。你看看java语言 。对于网站，除了查询扫描硬盘而产生的时间延迟，其它是不管的 ， 只要不算有问题就可以 。
连接方式是否为永久连接，在访问量未达到高并发之前，还是非永久链接更好 。非永久连接的资源消耗是不大于永久连接的，因为mysql是把连接权限缓存的 ， 不会多次扫描硬盘，性能是可执行级别的而不是查找数据级别的 。在访问量达到高并发之后，性能问题的原因是多方面的 ， 多环节的，是否为永久连接不是主要原因 。
关于怎么防止mysql死锁和mysql死锁处理方法的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站 。

    推荐阅读


    上一篇：go语言new关键字，go语言go关键字

    下一篇：工业级服务器价格 工业服务器机箱怎么样