mysql innodb 读加锁_[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

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