MySQL死锁分析：记一次因索引合并导致的MySQL死锁分析过程( 三 ) _MySQL死锁

T2持有锁space id 3680 page no 30

T2等待锁space id 3680 page no 137

最后回到了T2

可以推断space id 3680 page no 137应该被T1持有了，但是日志中没有显示出来。

3680 page no 30这个锁是一个主键索引PRIMARY导致的，实际上我们没有用到我们的自增主键，是非聚集索引，所以这是先锁的非主键索引最后找到的主键去加锁。
3680 page no 137这个锁就比较奇怪了，他锁在了idx_user_id这个索引，这个索引是加在userId上的，也就是T2他正在尝试锁所有这个用户的还款计划的记录！

如果是这样，问题就解释通了：

T1：锁了某行记录X（具体怎么锁的，从死锁日志中未能获取），然后准备去获取LN201907120655461690006528458116，SEQ=1的记录的锁。
T2：锁了LN201907120655461690006528458116，SEQ=1的锁，而他想去锁所有userId=938467411690006528的记录，这里面肯定包含了记录X，所以他无法获得X的锁。
这样就造成死锁了，因为X已经被T1持有了，而T1又在等T2释放LN201907120655461690006528458116，SEQ=1这个锁。

至于为什么T2明明准备操作
LN201906130129401690006528175485，SEQ=2的记录，却之前持有了
LN201907120655461690006528458116，SEQ=1的锁，大概率不是因为之前的SQL真的操作
LN201907120655461690006528458116，SEQ=1的记录，也是因为他之前本想持有别的记录（从锁的详细信息上猜，可能是
LN2019061301294016900065281754的相关记录），但是因为这个idx_user_id的索引问题，顺带锁着了
LN201907120655461690006528458116，SEQ=1，因为都属于一个userId 。

所以从时间线上分析，顺序应该是：

T1锁了某记录X
T2锁了某记录Y（从hold this lock的日志细节中推断，是LN2019061301294016900065281754），然后准备锁LN201906130129401690006528175485，SEQ=2，这时候的这条SQL触发了idx_user_id，连带一起锁锁住了LN201907120655461690006528458116，SEQ=1并准备锁其它同用户记录
T1 执行下一条sql，准备获取LN201907120655461690006528458116，SEQ=1的锁，发现被T2获取了，等待。
T2在锁其它记录的过程中发现了X，但是锁不住，发现X被T1持有。而自己又持有了LN201907120655461690006528458116，SEQ=1这行记录的锁。
这时候循环等待，死锁！