Innodb 死锁解析

近期查看线上日志，发现sql某个update语句每日278,110次有0.0061%概率发生异常，异常信息如下：

com.mysql.cj.jdbc.exceptions.MySQLTransactionRollbackException: Deadlock found when trying to get lock; try restarting transaction

进一步分析日志，原因是执行update语句的时候发生了死锁，mysql自动监测到了死锁后抛出的异常。

要查问题原因，首先要了解innodb执行更新时的大致原理。项目用的数据库是Mysql，引擎是innodb。在执行更新语句的时候，innodb的策略为：如果更新条件没有索引，则采用表锁的方式；如果条件有索引，采用行锁的方式。再往下细分，如果条件为主键索引，执行时会获取主键索引行锁；如果条件为非主键索引，执行时会先获取非主键索引行锁，然后获取对应主键索引行锁，完成更新一并释放行锁。

了解了原理，我们来具体分析死锁是如何发生的。首先，可以确认这个异常属于非主键索引不全导致的死锁，也就是当更新语句采用了非主键索引字段作为更新条件，在并发场景下，就会发生这样的情况：有两条更新语句，它们的更新条件存在相同的部分。例如：
A语句：update table_test set status = 1 where a = 1 and id = 999
B语句：update table_test set status = 2 where a = 1 and b =2
其中 a,b字段都有索引。A、B并发，且正好操作同一条记录，执行A时分为三步骤：
1、获取主键索引id的行锁
2、获取非主键索引a行锁
3、更新并释放锁
执行B时分为四步骤：
1、获取非主键索引a行锁
2、获取非主键索引b行锁
3、获取主键索引id的行锁
3、更新并释放锁
当A执行到1，B执行到2时，A等待B释放非主键索引a行锁，B等待A释放主键索引id的行锁，因此就造成了死锁。

解决办法：
尽量选择主键索引作为条件更新，遇到多条件更新，可以先按照条件查询出符合条件的记录，再根据主键逐个更新或批量更新。