在测试阶段,大数据并发的情况下,发现sql语句造成表的死锁,过一段时间,死锁消失。于是进行排查
报错如下:
对应的sql语句如下:
@Insert("replace into ${tableName}( windcode,date, \n" + " code, high, open, low, \n" + " `close`, volume, turnover,gtm_modify) " + "values (#{obj.windcode},#{obj.date},#{obj.code},#{obj.high},#{obj.open},#{obj.low},#{obj.close},#{obj.volume},#{obj.turnover},#{obj.updateTime})" ) int insertOne(@Param("obj") KDTO obj, @Param("tableName") String tableName);
在排除了数据问题和线程重复调用以后,我们关注了一下sql语句本身。 看了网上很多经验分享,觉得问题可能出现在 Replace Into 语句上。
首先我们分析一下为什么并发replace into导致MySQL死锁
Replace into 一般作用是,当存在冲突时,会把旧记录替换成新的记录。也就是说这条语句执行,分为了两个大步:判断和执行
1.判断:
首先判断我们需要操作的记录是否存在(根据主键或者唯一索引判断)
2.操作:
测试:
建立表
插入数据:
我们使用replace into语句去执行一个已经存在的数据:
可以清楚的发现,影响的行数是两行
第一行的数据被修改了
我们使用replace into语句去执行一个不存在的数据:
可以清楚的发现,影响的行数是一行
执行了插入操作:
逻辑非常的清晰,但是这种单条sql语句在什么情况下会出现死锁呢?我们就要去考虑这个加锁的时机。
正常的插入逻辑是:
发现错误:
转换模式:
如果发生uk冲突的索引是最后一个唯一索引、没有外键引用、且不存在delete trigger时,使用UPDATE ROW的方式来解决冲突;
否则,使用DELETE ROW + INSERT ROW的方式解决冲突。
更新记录:
所以死锁的问题多半就会出现在X记录锁上面。
死锁分析:
所以再多线程高并发的环境状态下,存在两个事务同时去获取一个记录的修改的情况:
所以在等待执行期间sql会有死锁报错,高并发环境下的死锁也就出现了,再事务执行完成回滚操作以后,死锁回滚,也就解释了死锁消失的问题。
经过多方讨论,最终决定使用 insetr + ON DUPLICATE KEY UPDATE语句替换高并发环境下的Replace Into语句解决死锁问题。
ON DUPLICATE KEY UPDATE语句的作用是:
若该数据的主键值/ UNIQUE KEY 已经在表中存在,则执行更新操作, 即UPDATE 后面的操作。
否则插入一条新的记录。
实现了Replace Into有相同的查重替换功能,而避免了高并发的死锁问题。
但是UPDATE操作性能相比DELETE操作会有一定的性能上的影响,需要后续测试跟进。
到此这篇关于高并发状态下Replace Into造成的死锁问题解决的文章就介绍到这了,更多相关Replace Into死锁内容请搜索以前的文章或继续浏览下面的相关文章希望大家以后多多支持!