官方文档：https://dev.mysql.com/doc/refman/5.6/en/innodb-locks-set.html
线上出现一个死锁现象，信息显示的是两条对同一个表的不同记录的update操作，表上只有一个主键索引，更新的条件上无索引，时间地段显示两个update只相差1ms
业务场景是同时一个事务中先是insert 再update新插入的行，存在并发；数据库环境是5.6，事务隔离级别RC，auto_increment_increment=1
通过定时任务实现两个会话同时对一个表先进行insert，然后update
#表结构 mysql> show create table test.t3; +-------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Table | Create Table | +-------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | t3 | CREATE TABLE `t3` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(10) DEFAULT NULL, `col` varchar(10) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=225 DEFAULT CHARSET=utf8 | +-------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ 1 row in set (0.00 sec) #定时任务 32 13 * * * for i in `seq 100`;do /usr/local/mysql/bin/mysql -uroot -S /tmp/mysql_3309.sock -e "begin;insert into test.t3 values(null,'aa','$i');update test.t3 set name='aa$i' where col='$i';commit;";done 32 13 * * * for i in `seq 100 200`;do /usr/local/mysql/bin/mysql -uroot -S /tmp/mysql_3309.sock -e "begin;insert into test.t3 values(null,'aa','$i');update test.t3 set name='aa$i' where col='$i';commit;";done
捕获到的死锁信息
------------------------ LATEST DETECTED DEADLOCK ------------------------ 2017-06-08 13:32:04 0x7f5277ba6700 *** (1) TRANSACTION: TRANSACTION 696509, ACTIVE 0 sec fetching rows mysql tables in use 1, locked 1 LOCK WAIT 3 lock struct(s), heap size 1136, 2 row lock(s), undo log entries 2 MySQL thread id 112, OS thread handle 139992172484352, query id 965 localhost root updating update test.t3 set name='aa26' where col='26' *** (1) WAITING FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 83 page no 3 n bits 152 index PRIMARY of table `test`.`t3` trx id 696509 lock_mode X locks rec but not gap waiting Record lock, heap no 82 PHYSICAL RECORD: n_fields 5; compact format; info bits 0 0: len 4; hex 8000004c; asc L;; 1: len 6; hex 0000000aa0be; asc ;; 2: len 7; hex b6000001910110; asc ;; 3: len 2; hex 6161; asc aa;; 4: len 3; hex 313236; asc 126;; *** (2) TRANSACTION: TRANSACTION 696510, ACTIVE 0 sec fetching rows mysql tables in use 1, locked 1 3 lock struct(s), heap size 1136, 2 row lock(s), undo log entries 1 MySQL thread id 113, OS thread handle 139992172750592, query id 966 localhost root updating update test.t3 set name='aa126' where col='126' *** (2) HOLDS THE LOCK(S): RECORD LOCKS space id 83 page no 3 n bits 152 index PRIMARY of table `test`.`t3` trx id 696510 lock_mode X locks rec but not gap Record lock, heap no 82 PHYSICAL RECORD: n_fields 5; compact format; info bits 0 0: len 4; hex 8000004c; asc L;; 1: len 6; hex 0000000aa0be; asc ;; 2: len 7; hex b6000001910110; asc ;; 3: len 2; hex 6161; asc aa;; 4: len 3; hex 313236; asc 126;; *** (2) WAITING FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 83 page no 3 n bits 152 index PRIMARY of table `test`.`t3` trx id 696510 lock_mode X locks rec but not gap waiting Record lock, heap no 83 PHYSICAL RECORD: n_fields 5; compact format; info bits 0 0: len 4; hex 8000004b; asc K;; 1: len 6; hex 0000000aa0bd; asc ;; 2: len 7; hex 3500000142133d; asc 5 B =;; 3: len 4; hex 61613236; asc aa26;; 4: len 2; hex 3236; asc 26;; *** WE ROLL BACK TRANSACTION (2) ------------
解决
mysql> explain update test.t3 set name='aa126' where col='126' -> ; +----+-------------+-------+------------+-------+---------------+---------+---------+------+------+----------+-------------+ | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | +----+-------------+-------+------------+-------+---------------+---------+---------+------+------+----------+-------------+ | 1 | UPDATE | t3 | NULL | index | NULL | PRIMARY | 4 | NULL | 382 | 100.00 | Using where | +----+-------------+-------+------------+-------+---------------+---------+---------+------+------+----------+-------------+ 1 row in set (0.00 sec)
更新操作会对主键索引进行全索引扫描，我的理解为会一行行的处理先在innodb层在主键上加X锁，然后再server层通过where条件进行过滤，释放不符合条件的记录上的锁
在where条件字段上加索引，避免全索引扫描
测试发现通过在where条件上添加索引可以解决问题，但是还是无法解释这一现象，因为单独将事务拿出来重现是不会产生阻塞的，只有高并发下才会产生。。。。有知道的朋友请留言。