mysql表死锁怎么解决,mysql表死锁简单粗暴

MySQL数据库中查询表是否被锁以及解锁

1.查看表被锁状态

创新互联公司专注于企业成都全网营销推广、网站重做改版、湘潭网站定制设计、自适应品牌网站建设、H5开发商城网站定制开发、集团公司官网建设、外贸营销网站建设、高端网站制作、响应式网页设计等建站业务,价格优惠性价比高,为湘潭等各大城市提供网站开发制作服务。

2.查看造成死锁的sql语句

3.查询进程

4.解锁(删除进程)

5.查看正在锁的事物  (8.0以下版本)

6.查看等待锁的事物 (8.0以下版本)

mysql死锁场景整理

本文死锁场景皆为工作中遇到(或同事遇到)并解决的死锁场景,写这篇文章的目的是整理和分享,欢迎指正和补充,本文死锁场景包括:

注 :以下场景隔离级别均为默认的Repeatable Read;

前提 :表 t_user 的 uid 字段创建了唯一索引,并拥有可更新字段age。

场景复现 :

相应业务案例和解决方案 :

该场景常见于事务中存在for循环更新某条记录的情况,死锁日志显示 lock_mode X locks rec but not gap waiting (即行锁而非间隙锁),解决方案:

表结构 :

场景复现 :

首先查询表中目前存在的记录:

执行两个事务的操作:

死锁原因分析 :

解决方案 :

t_user结构改造为:

场景复现操作(几率不高) :

假设存在以下数据 :

死锁分析 :

事务1 :

① 锁住zone_id=1对应的间隙锁: zoneId in (1,2)

② 锁住索引zone_id=1对应的主键索引行锁id = [1,2]

③ 锁住uid=1对应的间隙锁: uid in (1, 2)

④ 锁住uid=1对应的主键索引行锁: id = [1, 3]

事务2 :

① 锁住zone_id=2对应的间隙锁: zoneId in (1,2)

② 锁住索引zone_id=2对应的主键索引行锁id = [3,4]

③ 锁住uid=2对应的间隙锁: uid in (1, 2)

④ 锁住uid=2对应的主键索引行锁: id = [2, 4]

解决方案 :创建联合索引,使执行计划只会用到一个索引。

测试表结构 :

场景复现操作 :

解决办法:尽量避免这种插入又回滚的场景。

避免死锁的原则:

解决一次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发生死锁怎么解决

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


分享标题:mysql表死锁怎么解决,mysql表死锁简单粗暴
网站链接:http://csdahua.cn/article/dsdpgih.html
扫二维码与项目经理沟通

我们在微信上24小时期待你的声音

解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流