一次Mysql下批量更新造成的死锁案例分析
最近，公司现网的业务中出现上图所示的死锁异常，沿着问题分析，发现这个问题涉及很多数据库的基础知识。
背景：
使用数据库：Mysql
涉及表格：t_invest
数据库隔离级别：可重复读(Repeatable Read)
死锁场景：saveRepaymentInfo事务的A()方法对t_invest表执行如下update操作：
<update id = "A" parameterType = "java.util.List">
<foreach collecton = "list" item = "item" separator = ";">
update t_invest
set status = 1,
end_date = #{item.endDate},
period = #{item.periods},
update_time = now()
where invest_no = #{item.invest_no}
</foreach>
</update>
invest_no字段为设置了唯一索引
异常信息:
死锁分析：
通过异常日志跟踪定位到业务代码，发现死锁出现在syncRedeemApply事务。
事务syncRedeemApply会进行t_invest表的status的批量更新，批次最大数量为1000条。t_invest表的事务隔离级别为“可重复读”，在该隔离级别下，每次执行更新操作时会对索引加行锁，这个事务不存在多线程并发访问的情况，推断不是因为多程序并发操作造成的死锁。
通过分析业务功能发现，其他分布式业务模块在saveRepaymentInfo事务进行t_invest表的status的批量更新的同时，另外有一个updateExitStatusByBatch事务同时也在invest表进行批量更新，而且都是利用investno索引进行批量update，问题就出现在这里！
updateExitStatusByBatch事务进行批量更新的方法假设是B()，其批量更新语句为：
<update id = "B" parameterType = "java.util.List">
<foreach collecton = "list" item = "item" separator = ";">
update t_invest
set status = 1,
end_date = #{item.endDate},
period = #{item.periods},
update_time = now()
where invest_no = #{item.invest_no}
</foreach>
</update>
（其实两个事务的方法A与B的sql是一样的）
死锁是因为两个或两个以上的线程在执行过程中，由于竞争资源或者由于彼此通信而造成的一种阻塞的现象，若无外力作用，它们都将无法推进下去。此时称系统处于死锁状态或系统产生了死锁，这些永远在互相等待的进程称为死锁进程。
如下图所示：
t_fixin_invest的事务隔离级别为“可重复读”，每次执行更新操作时会对索引加行锁，在一个事务内批量修改如果没有全部修改完，索引是不会被放开的，亦即索引上的行锁不会被放开，所以当两个事务中同时进行更新时，如果有重复数据，有可能出现互相等待，从而爆死锁。
如上图，syncRedeemApply事务锁住i1、i3、i5，updateExitStatusByBatch事务锁住i2、i4、i6，syncRedeemApply事务执行到i2的update，等待updateExitStatusByBatch事务释放i2的锁，updateExitStatusByBatch事务执行到i1的updat，等待syncRedeemApply事务释放i1的锁，如此，两个事务互相等待，造成死锁。
我的解决办法是避免这两个事务操作使用相同的索引进行更新，给表t_fixin_invest增加一个联合索引（investno，pno），然后其中一个批量操作使用这个索引更新，可避免死锁！
