mysql死锁怎么处理 mysql解决死锁的基本方法

mysql 死锁排查

一、show ENGINE INNODB status

成都创新互联-成都网站建设公司，专注网站制作、成都网站设计、网站营销推广，域名与空间，虚拟空间，网站改版维护有关企业网站制作方案、改版、费用等问题，请联系成都创新互联。

查看死锁位置，分析。

二、

首先解决死锁可以从死锁发生的条件入手，最容易解决的就是更改获取资源的顺序；

其次是避免长事务，让事务执行的时间尽可能少，让事务的覆盖范围尽可能小，长事务会导致并发度降低，且会有更多的SQL查询延迟；

给整个方法加事务是否是必须的？可以不加事务的尽量不加。

mysql解决死锁问题

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

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

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

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

官方定义：

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

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

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

MySQL有两种死锁处理方式：

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

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

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

MySQL如何处理死锁

mysql发生死锁怎么解决

可直接在mysql命令行执行:show engine innodb status\G; 查看造成死锁的sql语句,分析索引情况,然后优化sql然后show processlist; 另外可以打开慢查询日志,linux下打开需在...

数据库死锁处理方法

mysql数据库死锁解决方法如下：

1、对于按钮等控件，点击后使其立刻失效，不让用户重复点击，避免对同时对同一条记录操作。

2、使用乐观锁进行控制。乐观锁大多是基于数据版本（Version）记录机制实现。即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个“version”字段来实现。读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。乐观锁机制避免了长事务中的数据库加锁开销（用户A和用户B操作过程中，都没有对数据库数据加锁），大大提升了大并发量下的系统整体性能表现。Hibernate 在其数据访问引擎中内置了乐观锁实现。需要注意的是，由于乐观锁机制是在系统中实现，来自外部系统的用户更新操作不受系统的控制，因此可能会造成脏数据被更新到数据库中。

解决一次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的锁相关知识。

通过搜索引擎，

锁的持有兼容程度如下表

那么再回到死锁日志，可以知道 :

事务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