前言：
最近经常碰到死锁问题，由于对这块代码不是很熟悉，而常持有对文档怀疑的观点。决定从几个死锁问题着手，好好把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
上面这几种非记录锁在什么时候加，对事务并发又有什么影响呢？ 下回分解。。。。
