分享一个MySQL死锁问题解决的方法

分享一个MySQL死锁问题解决的方法

一、环境

CentOS, MySQL 5.6.21-70, JPA

问题场景：系统有定时批量更新数据状态操作，每次更新上千条记录，表中总记录数约为500W左右。

二、错误日志

三、排查

排查后发现都是执行类似这样的语句出现问题的：

四、分析

搜索相关资料后发现，原来MySQL InnoDB并不一定都是行级锁。

相关参考资料片段如下：

锁选择

1）、如果更新条件没有走索引，例如执行”update from t1 set v2=0 wh
4000
ere v2=5;” ，此时会进行全表扫描，扫表的时候，要阻止其他任何的更新操作，所以上升为表锁。

2）、如果更新条件为索引字段，但是并非唯一索引（包括主键索引），例如执行“update from t1 set v2=0 where v1=9;”

那么此时更新会使用Next-Key Lock。使用Next-Key Lock的原因：

a）、首先要保证在符合条件的记录上加上排他锁，会锁定当前非唯一索引和对应的主键索引的值；

b）、还要保证锁定的区间不能插入新的数据。

3）、如果更新条件为唯一索引，则使用Record Lock（记录锁）。

InnoDB根据唯一索引，找到相应记录，将主键索引值和唯一索引值加上记录锁。但不使用Gap Lock（间隙锁）。

由于InnoDB预设是Row-Level Lock，所以只有「明确」的指定主键，MySQL才会执行Row lock (只锁住被选取的资料例) ，否则MySQL将会执行Table Lock (将整个资料表单给锁住)。

根据分析结论，猜测是在更新_task_tel表时Where条件中tel_id和task_id没有建立UNIQUE(唯一索引)原因;

五、解决

据此分析，尝试通过tel_id和task_id两个字段建立UNIQUE(唯一索引)来解决。 (也可以先查询出来，然后根据主键ID来更新，这样不会因表中数据量较大影响线上业务)。

通过此种方式解决后，问题没有再重现。

如果你的问题和我遇到的类似，可以尝试据此解决。

转载出处：http://www.php.cn/mysql-tutorials-354964.html