【MySQL】如何阅读死锁日志

一 前言
   
工欲善其事必先利其器,前面分析了很多死锁案例,并没有详细的介绍如何通过死锁日志来诊断死锁的成因。本文将介绍如何读懂死锁日志,尽可能的获取信息来辅助我们解决死锁问题。
二 日志分析
2.1 场景 
为了更好的学习死锁日志,我们需要提前了解死锁场景
MySQL 5.6 事务隔离级别为RR

  1. CREATE TABLE `ty` (
  2.   `id` int(11) NOT NULL AUTO_INCREMENT,
  3.   `a` int(11) DEFAULT NULL,
  4.   `b` int(11) DEFAULT NULL,
  5.   PRIMARY KEY (`id`),
  6.   KEY `idxa` (`a`)
  7. ) ENGINE=InnoDB AUTO_INCREMENT=8 DEFAULT CHARSET=utf8mb4
  8. insert into ty(a,b) values(2,3),(5,4),(6,7);

2.2 测试用例


T2


T1


begin;


delete from  ty where  a=5;


begin;


delete from  ty where  a=5;


insert into ty(a,b) values(2,10);


delete from  ty where  a=5;

ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction

                                                            
2.3 我们通过show engine innodb status 查看的日志是最新一次记录死锁的日志。

  1. ------------------------
  2. LATEST DETECTED DEADLOCK
  3. ------------------------
  4. 2017-09-09 22:34:13 7f78eab82700
  5. *** (1) TRANSACTION: #事务1
  6. TRANSACTION 462308399, ACTIVE 33 sec starting index read
  7. mysql tables in use 1, locked 1
  8. LOCK WAIT 2 lock struct(s), heap size 360, 1 row lock(s)
  9. MySQL thread id 3525577, OS thread handle 0x7f896cc4b700, query id 780039657 localhost root updating
  10. delete from ty where a=5
  11. *** (1) WAITING FOR THIS LOCK TO BE GRANTED:
  12. RECORD LOCKS space id 219 page no 4 n bits 72 index `idxa` of table `test`.`ty` trx id 462308399 lock_mode X waiting
  13. *** (2) TRANSACTION:
  14. TRANSACTION 462308398, ACTIVE 61 sec inserting, thread declared inside InnoDB 5000
  15. mysql tables in use 1, locked 1
  16. 5 lock struct(s), heap size 1184, 4 row lock(s), undo log entries 2
  17. MySQL thread id 3525490, OS thread handle 0x7f78eab82700, query id 780039714 localhost root update
  18. insert into ty(a,b) values(2,10)
  19. *** (2) HOLDS THE LOCK(S):
  20. RECORD LOCKS space id 219 page no 4 n bits 72 index `idxa` of table `test`.`ty` trx id 462308398 lock_mode X
  21. *** (2) WAITING FOR THIS LOCK TO BE GRANTED:
  22. RECORD LOCKS space id 219 page no 4 n bits 72 index `idxa` of table `test`.`ty` trx id 462308398 lock_mode X locks gap before rec insert intention waiting
  23. *** WE ROLL BACK TRANSACTION (1)

2.4 日志分析
*** (1) TRANSACTION: #事务1
TRANSACTION 462308399, ACTIVE 33 sec starting index read 
事务编号为 462308399 ,活跃33秒,starting index read 表示事务状态为根据索引读取数据。常见的其他状态:

  1. fetching rows 表示事务状态在row_search_for_mysql中被设置,表示正在查找记录。
  2. updating or deleting 表示事务已经真正进入了Update/delete的函数逻辑(row_update_for_mysql)
  3. thread declared inside InnoDB 说明事务已经进入innodb层。通常而言 不在innodb层的事务大部分是会被回滚的。

mysql tables in use 1, 说明当前的事务使用一个表。locked 1 表示表上有一个表锁,对于DML语句为LOCK_IX
LOCK WAIT 2 lock struct(s), heap size 360, 1 row lock(s)
LOCK WAIT表示正在等待锁, 2 lock struct(s) 表示trx->trx_locks锁链表的长度为2,每个链表节点代表该事务持有的一个锁结构,包括表锁,记录锁以及auto_inc锁等。本案例中2locks 表示IX锁和lock_mode X(Next-key lock)
heap size 360 表示事务分配的锁堆内存大小,一般没有什么具体的用处。
1 row lock(s)表示当前事务持有的行记录锁/gap 锁的个数。
delete from ty where a=5 表示事务1在执行的sql ,不过比较悲伤的事情是show engine innodb status 是查看不到完整的事务的sql 的,通常显示当前正在等待锁的sql。
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 219 page no 4 n bits 72 index `idxa` of table `test`.`ty` trx id 462308399 lock_mode X waiting
RECORD LOCKS 表示记录锁,space id为219,page号4 ,n bits 72表示这个聚集索引记录锁结构上留有72个Bit位
表示事务1 正在等待表 ty 上的 idxa 的 X 锁本案例中其实是Next-Key lock
事务2的log 和上面分析类似,
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 219 page no 4 n bits 72 index `idxa` of table `test`.`ty` trx id 462308398 lock_mode X
显示了事务2 insert into ty(a,b) values(2,10)持有了a=5 的Lock mode X |LOCK_GAP ,不过我们从日志里面看不到 事务2 执行的 delete from  ty where  a=5;这点也是造成DBA 仅仅根据日志难以分析死锁的问题的根本原因。
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 219 page no 4 n bits 72 index `idxa` of table `test`.`ty` trx id 462308398 lock_mode X locks gap before rec insert intention waiting
表示事务2的insert 语句正在等待插入意向锁 lock_mode X locks gap before rec insert intention waiting (LOCK_X + LOCK_REC_GAP )
这里需要各位注意的是锁组合,类似lock_mode X waiting ,lock_mode X,lock_mode X locks gap before rec insert intention waiting 是我们分析死锁的核心重点。如何理解锁组合呢?
首先我们要知道对于MySQL有两种常规锁模式
LOCK_S(读锁,共享锁)
LOCK_X(写锁,排它锁)
最容易理解的锁模式,读加共享锁,写加排它锁.
有如下几种锁的属性
LOCK_REC_NOT_GAP        (锁记录)
LOCK_GAP                       (锁记录前的GAP)
LOCK_ORDINARY              (同时锁记录+记录前的GAP 。传说中的Next Key锁)
LOCK_INSERT_INTENTION(插入意向锁,其实是特殊的GAP锁)
锁的属性可以与锁模式任意组合。例如.
lock->type_mode 可以是Lock_X 或者Lock_S 
locks gap before rec  表示为gap锁:lock->type_mode & LOCK_GAP
locks rec but not gap 表示为记录锁,非gap锁:lock->type_mode & LOCK_REC_NOT_GAP
insert intention          表示为插入意向锁:lock->type_mode & LOCK_INSERT_INTENTION
waiting                       表示锁等待:lock->type_mode & LOCK_WAIT
三 小结
  本文算是简单的死锁分析入门,能够提供部分死锁分析的所需要的技术知识。死锁分析确是一门技术活儿,想要透彻的分析死锁的成因,我们必须要了解造成死锁的业务逻辑sql 的执行场景MySQL的锁机制各种锁之间的兼容性,必要时还需要透彻的理解源码。

时间: 2024-09-28 23:52:02

【MySQL】如何阅读死锁日志的相关文章

[MySQL 学习] Innodb锁系统(1)之如何阅读死锁日志

前言: 最近经常碰到死锁问题,由于对这块代码不是很熟悉,而常持有对文档怀疑的观点.决定从几个死锁问题着手,好好把Innodb锁系统的代码过一遍. 以下的内容不敢保证完全正确.只是我系统学习的过程. /////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// 最近有同学发现,走二级索引删除数据时,两条delete

MySQL加锁及死锁处理分析

<MySQL加锁处理分析> 背景 MySQL/InnoDB的加锁分析,一直是一个比较困难的话题.我在工作过程中,经常会有同事咨询这方面的问题.同时,微博上也经常会收到 MySQL锁相关的私信,让我帮助解决一些死锁的问题.本文,准备就MySQL/InnoDB的加锁问题,展开较为深入的分析与讨论,主要是介绍一种思路,运用此思路,拿到任何一条SQL语句,都能完整的分析出这条语句会加什么锁?会有什么样的使用风险?甚至是分析线上的一个死锁场景,了解死锁产生的原因. 注:MySQL是一个支持插件式存储引擎

MySQL Innodb表导致死锁日志情况分析与归纳_Mysql

案例描述在定时脚本运行过程中,发现当备份表格的sql语句与删除该表部分数据的sql语句同时运行时,mysql会检测出死锁,并打印出日志.两个sql语句如下:(1)insert into backup_table select * from source_table(2)DELETE FROM source_table WHERE Id>5 AND titleWeight<32768 AND joinTime<'$daysago_1week'teamUser表的表结构如下:PRIMARY

【MySQL】漫谈死锁

一 前言     死锁是每个MySQL DBA 都会遇到的技术问题,本文自己针对死锁学习的一个总结,了解死锁是什么,MySQL如何检测死锁,处理死锁,死锁的案例,如何避免死锁.二 死锁    死锁 是并发系统中常见的问题,同样也会出现在Innodb系统中.当两个及以上的事务,双方都在等待对方释放已经持有的锁或者因为加锁顺序不一致造成循环等待锁资源,就会出现"死锁".举例来说A 事务持有x1锁 ,申请x2锁,B 事务持有x2锁,申请x1 锁.A和B 事务持有锁并且申请对方持有的锁进入循环

MySQL的6种日志详解

MySQL有6种日志,监控数据库系统的时候必须知道 select日志 slow select日志 变更日志 二进制变更日志(binlog) 告警日志 错误日志. 可以在my.cnf中配置 参数 说明 log 文本select日志,记下所有的MySQL的命令操作, log-update 文本变更日志 log-bin 这个都知道了,数据库复制的时候必备 binlog_cache_size 临时存放某次事务的SQL语句缓冲长度 max_binlog_cache_szie 最大二进制Cache日志缓冲区

mysql开启慢查询日志的例子

当项目大了之后,mysql每天处理海量的数据,难免会有一些慢查询,此时我们要开启慢查询日志,来看哪些sql语句是需要优化的.以下就是开启mysql慢查询日志的方法:   1. 进入mysql命令模式下,执行"set global slow_query_log=on;"来开启记录慢查询日志. 2. 以window为例,打开mysql的配置文件"my.ini",在后面加入如下配置: log-slow-queries = E:\\mysql_log\\slow_query

开启mysql和php慢日志方法

开启mysql慢日志 MySQL的慢查询日志是MySQL提供的一种日志记录,它用来记录在MySQL中响应时间超过阀值的语句,具体指运行时间超过long_query_time值的SQL,则会被记录到慢查询日志中.long_query_time的默认值为10,意思是运行10s以上的语句.默认情况下,Mysql数据库并不启动慢查询日志,需要我们手动来设置这个参数,当然,如果不是调优需要的话,一般不建议启动该参数,因为开启慢查询日志会或多或少带来一定的性能影响.慢查询日志支持将日志记录写入文件,也支持将

MySQL如何传输二进制日志

MySQL Replication可以很方便的用来做应用的读扩展,也可以帮MySQL实现一定程度的HA方案.MySQL通过向备库传送二进制日志来实现Replication,本文将通过二进制日志相关源代码的主要接口来解释:"MySQL如何传输二进制日志,是主库推,还是备库拉?MySQL日志传输的实时性如何?". 在MySQL Replication结构中,备库端初次通过CHANGE MASTER TO完成Replication配置,再使用start slave命令开始复制.更细致的,备库

mysql 开启慢查询 如何打开mysql的慢查询日志记录_Mysql

mysql慢查询日志对于跟踪有问题的查询非常有用,可以分析出当前程序里有很耗费资源的sql语句,那如何打开mysql的慢查询日志记录呢? 其实打开mysql的慢查询日志很简单,只需要在mysql的配置文件里(windows系统是my.ini,linux系统是my.cnf)的[mysqld]下面加上如下代码: 复制代码 代码如下: log-slow-queries=/var/lib/mysql/slowquery.log long_query_time=2 注: log-slow-queries