拼多多网站的类型项目推广

mysql 死锁问题及死锁权重分析

问题发生过程：
1、生产发现死锁一次
语句为sql1:UPDATE table set  data = ‘123’ where business_no = 'ABC';

该行数据的id=1， business_no = 'ABC'

tablbe 字段

id：主键 business_no为唯一索引字段，其他字段暂时无意义

2、查找发生死锁问题原因

上述sql在一个事务内,死锁必定有两把锁。

最开始对锁的理解就是锁主键、不清楚是否有其他锁参与。

网上搜索发现update的where条件为唯一索引时候，sql会同时获取两把锁，先获取唯一索引business_no的锁,再获取主键id的锁，所以必定同一时刻有先获取id锁，再获取唯一主键锁的sql。

查找代码返现同一时刻,另外一个事务2执行了以下sql

sql2：UPDATE table set  data = ‘123’ where id = 1;

sql3:UPDATE table set  data = ‘123’ where business_no = ‘ABC’；

现在发现了死锁原因：

但是现象不复核预期

sql 1 先唯一键锁、后 主键锁

sql2 先主键锁 、sql3后唯一键锁

理论是sql1 和 sql3 都有可能发生死锁，因为sq1在一个sql内，sql2、slq3是分开的，

按预期sql3发生死锁错误的概率最大，但是代码发生了8次死锁全部是sql1发生了死锁。

3、为啥sql1发生死锁

第一步怀疑有其他sql参与了，但是没找到疑点sql。

网上搜索发现了一个死锁权重的概念。

大概意思是发生死锁根据算法确定权重，权重小的事务会回滚。

感觉问题快找到了，猜想sql1事务内只有一个事务（他基本就是小权重的事务）。

那接下来分析日志验证：

事务2还执行了以下sql。

sql4：UPDATE table2 set  data2 = ‘123’ where id = 1;

在sql2和sql3之前还有sql4。

那猜测有事务4  中sql5  UPDATE table2 set  data2 = ‘345’ where id = 1;

让后搜索日志发现同一时间有有sql5。

接下来实际验证：

开启事务1：

执行：sql2：UPDATE table set  data = ‘123’ where id = 1;

执行sql4：UPDATE table2 set  data2 = ‘123’ where id = 1;

开启事务2：

执行slq1:UPDATE table set  data = ‘123’ where business_no = 'ABC';

开启事务3：

执行sql5：UPDATE table2 set  data2 = ‘345’ where id = 1;

事务1：

执行slq3：UPDATE table set  data = ‘123’ where business_no = ‘ABC’；

发现必sql1必死锁异常且回滚，问题解决。

4、问题总结

msql行级锁加锁的过程。

mysql发生死锁回滚的机制。