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

前言:

最近经常碰到死锁问题,由于对这块代码不是很熟悉,而常持有对文档怀疑的观点。决定从几个死锁问题着手,好好把Innodb锁系统的代码过一遍。

以下的内容不敢保证完全正确。只是我系统学习的过程。


///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

最近有同学发现,走二级索引删除数据时,两条delete出现死锁。

我们可以保证二级索引记录是唯一的,按理说回表查到的主键记录不可能相同。死锁的现象如下所示:


*** (1) TRANSACTION:

TRANSACTION 1E7D49CDD, ACTIVE 69 sec fetching rows

mysql tables in use 1, locked 1

LOCK WAIT 4 lock struct(s), heap size 1248, 4 row lock(s), undo log entries 1

MySQL thread id 1385867, OS thread handle 0x7fcebd956700, query id 837909262 10.246.145.78 im_mobile updating

delete    from        offmsg_0007    WHERE     target_id = ‘Y25oaHVwYW7mmZbmmZblpKnkvb8=’      and         gmt_modified <= ‘2012-12-14 15:07:14’

*** (1) WAITING FOR THIS LOCK TO BE GRANTED:

RECORD LOCKS space id 203 page no 475912 n bits 88 index `PRIMARY` of table `im_mobile`.`offmsg_0007` trx id 1E7D49CDD lock_mode X locks rec but not gap waiting

*** (2) TRANSACTION:

TRANSACTION 1E7CE0399, ACTIVE 1222 sec fetching rows, thread declared inside InnoDB 272

mysql tables in use 1, locked 1

1346429 lock struct(s), heap size 119896504, 11973543 row lock(s), undo log entries 1

MySQL thread id 1090268, OS thread handle 0x7fcebf48c700, query id 837483530 10.246.145.78 im_mobile updating

delete    from        offmsg_0007    WHERE     target_id = ‘Y25oaHVwYW7niLHkuZ3kuYU5OQ==’      and         gmt_modified <= ‘2012-12-14 14:13:28’

*** (2) HOLDS THE LOCK(S):

RECORD LOCKS space id 203 page no 475912 n bits 88 index `PRIMARY` of table `im_mobile`.`offmsg_0007` trx id 1E7CE0399 lock_mode X

*** (2) WAITING FOR THIS LOCK TO BE GRANTED:

RECORD LOCKS space id 203 page no 1611099 n bits 88 index `PRIMARY` of table `im_mobile`.`offmsg_0007` trx id 1E7CE0399 lock_mode X waiting


简单的介绍下死锁信息中所代表的含义,及对应变量(死锁日志在函数lock_deadlock_recursive中打印):

–>TRANSACTION 1E7D49CDD, ACTIVE 69 sec fetching rows    

事务活跃了69秒,事务状态为fetching rows

“fetching rows”事务状态在row_search_for_mysql中被设置,表示正在查找记录。

如果已经真正进入了Update/delete的函数逻辑(row_update_for_mysql),则状态为”updating or deleting”


该事务不在innodb层(没有thread declared inside InnoDB),十有八九被suspend了发现死锁,选为牺牲者 :-(.


–>mysql tables in use 1, locked 1         

in use 1有一个表被使用(trx->n_mysql_tables_in_use) ,在函数ha_innobase::external_lock中trx->n_mysql_tables_in_use被递增。

locked 1表示表上有一个表锁(加锁函数为lock_table,trx->mysql_n_tables_locked),对于DML语句为LOCK_IX


–>LOCK WAIT 4 lock struct(s), heap size 1248, 4 row lock(s), undo log entries 1

LOCK WAIT表示正在等待锁(trx->que_state)

4 lock struct(s) 表示trx->trx_locks锁链表的长度为4,每个链表节点代表该事务持有的一个锁结构,包括表锁,记录锁以及autoinc锁等。


heap size 1248表示事务分配的锁堆内存大小(trx->lock_heap),trx->trx_locks链表节点内存都从这个堆中分配。


4 row lock(s)表示当前事务持有的行记录锁个数,调用函数lock_number_of_rows_locked遍历trx->try_locks,找出其中类型为LOCK_REC的记录数。

注意,由于函数lock_number_of_rows_locked采用遍历的方式,因此在执行类似show engine innodb status时,可能产生大量的CPU时间片消耗,我们在生产环境曾经观察到该函数占用50%以上的时间片。


undo log entries 1表示当前只有一个Undo log记录,说明实际更新了一条聚集索引记录(二级索引不记undo)


–>RECORD LOCKS space id 203 page no 475912 n bits 88 index `PRIMARY` of table `im_mobile`.`offmsg_0007` trx id 1E7D49CDD lock_mode X locks rec but not gap waiting

等待/持有的锁记录,RECORD LOCKS表示记录锁,space id 为203(对应的是聚集索引),page号为475912

n bits 88表示这个聚集索引记录锁结构上留有88个Bit位(lock_rec_get_n_bits(lock), lock->un_member.rec_lock.n_bits),n_bits表示锁bitmap的bit数,该page上的记录数+64

id为1E7D49CDD的事务占有这个锁。

lock_mode X表示该记录锁为排他锁:lock->type_mode & LOCK_MODE_MASK

其他还有:

” 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


上面这几种非记录锁在什么时候加,对事务并发又有什么影响呢? 下回分解。。。。

原创文章,转载请注明: 转载自Simple Life

本文链接地址: [MySQL 学习] Innodb锁系统(1)之如何阅读死锁日志

Post Footer automatically generated by wp-posturl plugin for wordpress.


Comments

Leave a Reply

Your email address will not be published. Name and email are required


Current month ye@r day *