mysql中怎么处理死锁,mysql解决死锁

mysql发生死锁怎么解决

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

仪征ssl适用于网站、小程序/APP、API接口等需要进行数据传输应用场景,ssl证书未来市场广阔!成为创新互联建站的ssl证书销售渠道,可以享受市场价格4-6折优惠!如果有意向欢迎电话联系或者加微信:18980820575(备注:SSL证书合作)期待与您的合作!

数据库死锁处理方法

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

show engine innodb status

mysql 死锁排查

一、show ENGINE INNODB status

查看死锁位置,分析。

二、

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

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

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


文章名称:mysql中怎么处理死锁,mysql解决死锁
网页网址:http://pwwzsj.com/article/dscjdoo.html