做IT的险些每天都打仗 MySql，但是 Mysql 事务去世锁却并不常见，前段韶光就让我碰着了。非常日志如下
从日志看是发生了 Lock wait timeout exceeded 非常。
Lock wait timeout exceeded：后提交的事务等待前面处理的事务开释锁，但是在等待的时候超过了mysql的锁等待韶光，就会引发这个非常。
PreparedStatementCallback;SQL[UPDATEsf_wx_keyword_ruleSETstatus=?,last_update_time=last_update_timeWHEREid=?];Lockwaittimeoutexceeded;tryrestartingtransaction;
发生非常的代码紧张逻辑如下
剖析后实在是由于一个处理流程里开了两个事务，并更新的同一条数据，导致的事务间去世锁。
外层方法通过@Transactional 开启了事务1（@t1），对 sf_wx_keyword_rule 一条数据做更新，内层方法通过 REQUIRES_NEW 又开启了一个新事务2（@t2），并对sf_wx_keyword_rule 的同一条数据做更新。
begin@t1;UPDATEtableSETstatus=?WHEREid=1begin@t2;UPDATEtableSETstatus=?WHEREid=1commit@t2;commit@t1;
结论：由于 @t1 和 @t2 更新的是同一条数据，以是 @t2 的实行须要依赖 @t1 的提交，而@t1 的提交又须要 @t2 实行完。以是两个事务相互等待对方提交导致去世锁。
02. 复现及深层缘故原由追踪2.1 复现
为了搞清楚事务去世锁，及去世锁期间 MySql 的数据状态，新建 test1 表重复上述操作
过了大概 30s @t2 返回锁超时，与非常日志同等。
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction2.2 缘故原由追踪2.2.1 事务状态
Mysql 事务操作会涉及到三张表
//当前正在实行的每个事务的信息information_schema.innodb_trx//当前事务持有的锁记录information_schema.innodb_locks// 当前被壅塞的事务锁记录information_schema.innodb_lock_waits
查询 innodb_trx 表
紧张字段的含义
当前有两个未提交的事务，trx_id=21245712 状态为 LOCK WAIT，这条事务产生了一个 id为 21245712:565:3:2 (innodb_locks 表的id) 的锁，也便是该事务的 LOCK由于被壅塞而导致事务超时。
trx_id = 21245684 是实行完 SQL 还未提交的事务。
2.2.2 MySql 锁innodb_locks InnoDB 锁记录紧张字段含义
锁在 MySql 事务里是非常紧张的，上面的事务便是通过 Primary (主键) 在 Record (行) 上加的X (写) 锁，先加的 X 锁会成功，后加的 X 锁就会被壅塞。下面详细理解一下几个紧张的锁。
基本锁
InnoDB 行级锁，分为共享锁（S）和独占锁（X）
共享锁（Sharaed Locks: S锁），或叫读锁mysql许可拿到S锁的事务读一行加了S锁记录，许可其他事务再加S锁，不许可其他事务再加X锁语法：select ... lock in share mode;独占锁（Exclusive Locks:X锁）或叫写锁mysql许可拿到X锁的事务更新或删除一行加了X锁的记录，不许可其他事务再加X锁或S锁语法：select … for update;以是涌现上述事务去世锁超时的缘故原由是 UPDATE 会在记录上加 X 锁，壅塞了另一个事务对同一数据加的 X 锁。
延伸一下，有 X 锁之后，我们还能正常的读数据吗？答案是可以的。
select from test1;
普通的 SELECT 语句上没有加锁，只有 select ... lock in share mode; 才会加 S 锁。
下面是 MySql 的其他锁
意向锁
InnoDB为了支持多粒度（表锁和行锁）的锁并存，引入意向锁。意向锁是表级锁，分为IS锁和IX锁。
意向共享锁（IS）事务在要求S锁前，须要先得到对应的IS锁意向排他锁 （IX）事务在要求X锁前，须要先得到对应的IX锁锁兼容矩阵
自增锁 auto-inc lock
AUTO-INC锁是事务中的一种分外的表级锁，通过AUTO_INCREMENT的列来实现，这种锁是浸染于语句的而不是事务。
记录锁 record Lock
即行锁。单条索引记录上加锁，record lock锁住的永久是索引，而非记录本身。
间隙锁 gap lock
区间锁, 仅仅锁住一个索引区间(开区间)。在索引记录之间的间隙中加锁，或者是在某一条索引记录之前或者之后加锁，并不包括该索引记录本身。GAP锁的目的是为了防止同一事务的两次当前读，涌现幻读的情形。
临键锁 next key lock
行锁和间隙锁组合起来就叫Next-Key-Lock，左开右闭区间。默认情形下，innodb利用next-key locks来锁定记录。但当查询的索引含有唯一属性的时候，Next-Key Lock 会进行优化，将其降级为Record Lock，即仅锁住索引本身，不是范围。
插入意向锁 insert intention lock
Gap Lock中存在一种插入意向锁（Insert Intention Lock），在insert操作时产生。在多事务同时写入不同数据至同一索引间隙的时候，并不须要等待其他事务完成，不会发生锁等待。 假设有一个记录索引包含键值4和7，不同的事务分别插入5和6，每个事务都会产生一个加在4-7之间的插入意向锁，获取在插入行上的排它锁，但是不会被相互锁住，由于数据行并不冲突。
注：插入意向锁并非意向锁，而是一种分外的间隙锁。
如果插入前，该间隙已经有gap锁，那么insert 会申请插入意向锁。由于了避免幻读，当其他事务持有该间隙的间隔锁，插入意向锁就会被壅塞（不用直接用gap锁，是由于gap锁不互斥）。
innodb_lock_waits 被壅塞的锁记录这张表里有记录就解释有事务被壅塞里。
紧张字段含义
03. 办理方案及总结
线上碰着去世锁怎么办理？最快的办法当然是 kill 事务，重启做事，根本缘故原由还是须要看这三张表，往后再碰着数据库去世锁、事务去世锁，查这三张表就差不多知道缘故原由了。
我们该如何避免去世锁呢？常规的回答都因此固定的顺序访问数据。但本案例是由于利用了 REQUIRES_NEW 导致。
利用 REQUIRES_NEW 的缘故原由以了局景，内层事务是一个批量更新，但是又不肯望由于某一条失落败而影响其他的更新。
begin@t1aMapper.update()forpojoinpojos: begin @t2bMapper.update(pojo)rpc.update()commitcommit
以是一定要避免内外双层事务修正同一条数据的情形，对付 Spring 事务传播机制也要熟知其浸染。
要担保数据的终极同等性，该当写成一个Job，更新失落败后不断的去补偿。
"大众号：看起来很美（kanqilaihenmei_）
