代码定位按照死锁的update sql语句，我们先定位这个死锁SQL中代码是哪个代码片段导致的 。后面我们定位到，是如下代码片段导致的：
文章插图
实际上一眼看上去，这段代码有一个很典型的业务开发场景问题：开启事务在for循环写SQL 。
注：这在实际的问题定位过程中并不容易，因为死锁日志并不能反向直接定位到方法的对账、线程名等，如果一个库被多个服务同时连接，甚至定位是哪个服务都不容易 。死锁分析（1）——猜测可能消息重发
- 按照死锁的必要条件：循环等待条件 。即 T1事务应该持有了某把锁L1，然后去申请锁L2，而这时候发现T2事务已经持有了L2，而T2事务又去申请L1，这时候就发生循环等待而死锁 。
- 一开始会猜测，是否我们更新表的顺序在两个事务里面是反方向的，即T1事务更新ta、tb表，锁ta表的记录，准备去拿tb表记录的锁；T2事务更新tb、ta表，锁了tb记录准备去拿ta的锁，这是比较常见的死锁情况 。但是从SQL看，我们死锁的SQL是同一张表的，即同一张表不同的记录 。
- 而且从死锁日志中可以发现，两个死锁的SQL居然是“一样”的，也就是说是“同一条”SQL/同一段代码（不同的where条件参数）导致的，。即上图代码中的这段for循环更新还款计划的代码 。
- 但是光这段For循环来看，如果要发生死锁，有可能同一批请求，更新记录的顺序是反过来的，然后又并发执行的时候，可能出现 。
- 一开始会猜测上游触发了两条一样的请求（我们这个场景是MQ重发），出现了并发，两条消息分在两个事务中并发执行 。但是如果是MQ导致的原因，FOR循环更新的记录顺序是一样的，一样的顺序意味着一样的一样的加锁顺序，一样的加锁顺序意味着最多出现获取锁超时，不会满足【循环等待】的条件，不可能死锁 。所以排除MQ重发的可能 。
通过出现了几次的死锁，总结出了其相同的规律：每次的死锁SQL条件都有一样的特征——相同的userId+不同的借据+并发 。基本可以断定，相同的用户在同时还款多笔的时候，可能会发现死锁，但很可惜，测试环境、生产环境我们模拟这个场景都无法复现死锁的情况 。
只能靠技术手段分析原因了 。
- 思路：这是了两个完全不同的借据环境计划，操作完全不一样的数据记录，为什么会发生死锁呢？是不是锁的不是行而是锁了表？
死锁日志分析从事务1中的
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:RECORD LOCKS space id 3680 page no 30 n bits 136 index `PRIMARY` of table `db_loan_core_2`.`repay_plan_info_1` trx id 424487272 lock_mode X locks rec but not gap waiting事务2中的*** (2) HOLDS THE LOCK(S):RECORD LOCKS space id 3680 page no 30 n bits 136 index `PRIMARY` of table `db_loan_core_2`.`repay_plan_info_1` trx id 424487271 lock_mode X locks rec but not gap从RECORD LOCKS的标示可知，的确锁的是行锁不是表锁 。且从”but not gap”的信息来看，也不存在间隙锁（注：我们线上隔离级别是read committed,本来就不存在间隙锁问题） 。所以锁的位置应该的确是我们操作的行记录才对 。但是非常奇怪的是，实际业务上操作的记录的确是完全隔离的（因为是不同的借据，记录没有交集），为什么会冲突呢？【MySQL死锁分析：记一次因索引合并导致的MySQL死锁分析过程】再细节阅读死锁日志从事务2中获取到了一点线索：
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:RECORD LOCKS space id 3680 page no 137 n bits 464 index `idx_user_id` of table `db_loan_core_2`.`repay_plan_info_1` trx id 424487271 lock_mode X locks rec but not gap waiting Record lock, heap no 161 PHYSICAL RECORD: n_fields 2; compact format; info bits 0这个索引很奇怪，是userid的索引？分析之前，我们先看先看锁持有情况：
