MySQL数据库死锁分析

背景说明:

公司内部一套自建分布式交易服务平台,在POC稳定性压力测试的时候出现了数据库死锁。(InnoDB引擎)由于保密性,假设是app_test表死锁了。

现象:

发生异常:Deadlock found when trying to get lock; try restarting transaction

分析思路:

1、回忆和查找相关资料,InnoDB死锁导致的原因。

第一:涉及多表访问,两个事务相互占有对方需要的锁。假设有A表(含有初始化记录1)和B表(含有初始化记录2)。进行如下操作会发生死锁。(先设置set autocommit=0; 不自动提交事务)

事务1: updateA表记录1,where条件带主键索引。         事务2: updateB表记录2 ,where条件带主键索引

事务1:updateB表记录2 ,where条件带主键索引            事务2: updateA表记录1,where条件带主键索引 (Deadlock)

第二:单表单记录访问,两个事务相互占有对方需要的锁。假设有A表(含有初始化记录1) 进行如下操作会发生死锁  (先设置set autocommit=0; 不自动提交事务)

事务1: select A表记录1 lock in share mode where条件带主键索引。 事务2:select A表记录1 lock in share mode where条件带主键索引。

事务2: updateA表记录1 where条件带主键索引                                   事务2: updateA表记录1 where条件带主键索引  (Deadlock)

2、查看根据死锁的sql语句找到代码逻辑。下面代码逻辑就仅仅以操作数据库的形式体现。(毕竟数据库经过这么多人的验证,先怀疑是否程序操作数据库有问题。)

begin;

select liusmc ,huancdx ,buchang ,liuszdz ,liuszxz ,dangqzh  from app_test where liusbm = ‘chkseq‘ AND xitongbs = ‘110‘ AND farendma = ‘985‘ for update;   

UPDATE app_test SET liusmc = ‘chkseq‘, huancdx = 10000, buchang = 1, liuszdz = 99999999, liuszxz = 0, dangqzh = 3380100 WHERE liusbm = ‘chkseq‘ AND xitongbs = ‘110‘ AND farendma = ‘985‘ ;

commit;

3、根据代码逻辑分析,sql采用的是 for update 添加的排他锁,而且是单表操作,还检查了表的索引情况(此表无索引,此处很关键),于是潜意识里面 排除了,第一和第二个导致死锁的原因。此处又陷入死胡同。能想到的两个原因都排除了。

4、于是想使用show engine innodb status 命令来查询Deadlock的具体信息究竟是那两个事务锁住了什么资源,导致了死锁。但是奈何没有数据库权限。又不好意思直接问甲方的管理员要。所以还是先自己梳理思路,查询相关资料。

5、后来决定模拟下代码逻辑操作数据库的场景。毕竟就一个事务select for update了一个表然后再update,两个事务执行这个的先后顺序,以及查询的是否相同记录也是容易模拟。于是模拟了以下场景。

场景模拟:

1、两个事务,事务1 先select for update 记录1  ,事务2 select for update 记录1  ;事务1 update记录1 (此场景不会死锁)

2、两个事务,事务1 先select for update 记录1  ,事务2 select for update 记录2  ;事务1 update记录1 (居然死锁发生了,不是说InnoDB引擎 在表无索引的情况下是锁表的么?知识范围有缺陷还是深度不够?此时的我真的在心中万马奔腾啊)

思绪良久,翻阅了好多资料,实在想不通了,于是厚着脸皮也不怕影响POC成绩的情况下,请教了甲方老的DBA协助查看下。DBA叫我复现以下,我说明了现象以及原因。然后也复现了。

DBA的回复是:

事务1 持有锁   事务2需要事务1持有的锁,事务1 的update操作需要获取锁,所以出现了回路,发生死锁。外带了一句主要问题where条件多列检测索引。解决方法就是添加索引。由于DBA领导一句话,要是这个原因清楚了,此话题就到此结束。所以没敢多问,环境维护人员漏加索引了(此表本来有主键索引的)。

对于DBA的这个解释,”还是没有懂,事务1持有锁,事务2需要事务1持有的锁。事务1 update操作需要获取这个锁,所以出现了回路,发生了死锁。”  事务2只是在等待这个事务1 占有的锁而已,为何事务1的update操作需要获取锁会被事务2 占有。难道在等待也是算占有的? 如果等待也算是占有的话,那么场景1模拟的也应该会是死锁。所以明显不是。

DBA查看的日志信息的时候给了一个截图很关键,app_test 的索引 gen_clust_index 被锁住了。我觉得原因出在这个隐藏主键上面。InnoDB在表无唯一索引和主键的情况下,会自动创聚焦索引。

select * from information_schema.INNODB_LOCKS;
select * from information_schema.INNODB_LOCK_WAITS;

当两个事务进程 select for update where条件 使用同一个主键的时候,INNODB_LOCKS 会有两个事务进行的锁定信息,INNODB_LOCK_WAITS也会有一条记录,这个问题,以后待补充查证吧。

原文地址:https://www.cnblogs.com/mjoker0416/p/10756712.html

时间: 2024-11-05 17:25:03

MySQL数据库死锁分析的相关文章

mysql数据库死锁的产生原因及解决办法

这篇文章主要介绍了mysql数据库锁的产生原因及解决办法,需要的朋友可以参考下 数据库和操作系统一样,是一个多用户使用的共享资源.当多个用户并发地存取数据 时,在数据库中就会产生多个事务同时存取同一数据的情况.若对并发操作不加控制就可能会读取和存储不正确的数据,破坏数据库的一致性.加锁是实现数据库并 发控制的一个非常重要的技术.在实际应用中经常会遇到的与锁相关的异常情况,当两个事务需要一组有冲突的锁,而不能将事务继续下去的话,就会出现死锁,严 重影响应用的正常执行. 在数据库中有两种基本的锁类型

nagios 添加自定义监控项目监控mysql数据库死锁

nagios 添加自定义监控项目 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 系统环境:CentOS Linux release 7.2.1511 (Core) nagios 版本: 2.15 这里配合pt-dead-logger插件了,运行了这个插件,有死锁就会在test.deadlocks表写入死锁的信息 这里通过检测这个表是否增加了行数来发报警 nagios客户端自定义脚本: ###这里为了省事,直接把数据库的用户,

Mysql数据库引擎分析

先来一篇博文:http://www.jb51.net/article/38004.htm 这篇自我感觉写的还不错.大家可以看看. 1.什么是数据库引擎 简单来说就是数据库用于存储.处理和保护数据的核心服务.利用数据库引擎可控制访问权限并快速处理事务,从而满足企业内大多数需要处理大量数据的应用程序的要求.使用数据库引擎创建用于联机事务处理或联机分析处理数据的关系数据库,这包括创建用于存储数据的表和用于查看.管理和保护数据安全的数据库对象. 2.mysql数据库引擎类型(百度百科) 2.1 ISAM

MySQL 数据库死锁

数据库死锁 死锁的解决办法(1) 执行下面SQL,先查看哪些表被锁住了: select b.owner,b.object_name,a.session_id,a.locked_mode from v$locked_object a,dba_objects b where b.object_id = a.object_id; 查处引起死锁的会话 select b.username,b.sid,b.serial#,logon_time from vlocked_object a,vsession b

Mysql查询语句使用select.. for update导致的数据库死锁分析

近期有一个业务需求,多台机器需要同时从Mysql一个表里查询数据并做后续业务逻辑,为了防止多台机器同时拿到一样的数据,每台机器需要在获取时锁住获取数据的数据段,保证多台机器不拿到相同的数据. 我们Mysql的存储引擎是innodb,支持行锁.解决同时拿数据的方法有很多,为了更加简单,不增加其他表和服务器的情况下,我们考虑采用select... for update的方式,这样X锁锁住查询的数据段,表里其他数据没有锁,其他业务逻辑还是可以操作. 这样一台服务器比如select .. for upd

记一次线上MySQL数据库死锁问题

最近线上项目报了一个MySQL死锁(DealLock)错误,虽说对业务上是没有什么影响的,由于自己对数据库锁这块了解不是很多,之前也没怎么的在线上碰到过.这次刚好遇到了,便在此记录一下. 出现死锁问题背景 项目层面:报错的项目做的是一个批量下单的动作,会同时写入多条订单数据,代码之前写的是一个事务中一个循环一条一条insert到数据库(至于为啥没用批量插入就不追究了,历史原因了). 数据库层面:一张test表(非线上真实表),比较重要的是有一个 type 和 name的唯一索引. 事务隔离级别:

mysql数据库死锁

当我们频繁的对数据库进行插入或更新的时候,有可能会直接报sql错误1205:lock wait timeout exceeded.数据库的死锁. 一般INNODB数据库会自动添加事务,当进行插入或者更新的时候,如果上次commit尚未执行完,而又有一次新的commit提交的时候,系统就会报SQL错误1205:lock wait timeout exceeded.这就是mysql死锁. 作为一个新手,碰到这样苦逼的事情自然是手足无措.于是赶紧上网看看解决方案,不负所望,网上还真找到相应的结局方案,

mysql innodb 死锁分析

mysql Ver 14.14 Distrib 5.7.16, for linux-glibc2.5 (x86_64) using EditLine wrapper #mysql版本 5.7.16 Connection id: 10042 Current database: china9129 Current user: [email protected] SSL: Not in use Current pager: stdout Using outfile: '' Using delimite

mysql数据库死锁 情景一

备注:CI的SQL构造器,若果数据是int类型的话必须用intval进行转换 有一张查询很频繁的表,然后尝试根据主键去更新某一个字段,SQL如下: update node_bird set Isverify=1 where NodeID='912399'; 发现NodeID原本是int,CI的sql构造器将NodeID生成SQL语句的时候加了单引号,然而这张表的查询比较多,导致后面的查询都死掉了