目录
1 .出现问题：
2 .通过分析解决
3 .解决方案：
在1.问题出现：测试阶段，如果并发了大数据，则会发现sql语句对表的死锁，一会儿死锁就会消失。 在那里进行故障诊断
错误如下。
对应的sql语句如下：
@ insert (replace into $ { tablename } ) windcode、date、\n’ ‘ code、high、open、low、\n’ ‘ `close `、volume、ge #{obj.code}、#{obj.high}、# { obj.open } # { obj.update time } ((intinsertone ) param ) ) obj ) KDTO obj，@ ppate 在排除了数据问题和线程的重复调用后，我们关注了sql语句本身。 看了网上很多经验共享，我觉得问题可能出在Replace Into语句上。
首先我们分析一下为什么并发replace into导致MySQL死锁
Replace into的常见作用是在发生冲突时用新记录替换旧记录。 也就是说，该语句的执行分为判断和执行两大步骤
1 .判断：
首先，判断是否有需要操作的记录。 (根据主键或者唯一索引判断)。
2 .操作：
对于不存在的记录，语句执行insert并插入操作。
对于已存在的记录，语句可以拆分为delete insert操作
测试：
创建表
插入数据：
使用replace into语句运行已经存在的数据。
很明显，产生影响的行数为两行
修改了第一行中的数据
我们使用replace into语句运行不存在的数据。
很明显，产生影响的行数为1行
已执行插入操作：
虽然逻辑非常清楚，但是这个单个sql语句在什么情况下会发生死锁呢？ 我们必须考虑打开这个锁的时机。
正常的插入逻辑是：
首先插入聚集索引记录。 在上面的示例中，id列是自增加列。
然后，由于它是唯一索引，因此在检查duplicate key时，插入辅助索引num以添加LOCK_X类型的记录锁。
发现错误：
由于检测到duplicate key，因此必须回滚在第一步中插入的聚合索引记录。 (row_undo_ins )。
在从InnoDB层返回Server层失败后，它会收到duplicate key错误，首先查找唯一密钥冲突的索引，然后锁定冲突的索引记录(和聚合索引记录)。
转换模式：
如果发生uk冲突的索引是最后一个唯一索引，没有外键引用，并且delete trigger不存在，请使用UPDATE ROW解决冲突。
否则，使用DELETE ROW INSERT ROW解决冲突。
更新记录：
对于聚合索引，由于PK列发生了更改，因此用delete insert聚合索引记录方法进行了更新。
对于2级uk索引，也采用了删除标签插入方式。
所以死锁的问题多半就会出现在X记录锁上面。
死锁分析：
因此，在多线程、并发的环境中，两个事务可能同时获取一个记录的更改。
取得事务1x记录锁定，
事务2检测到冲突，获取X|NK锁定，并被事务1阻止
事务1检测到冲突，申请获取S|NK，并被事务2阻止
事务处理1事务处理2 lock _ xlock _ not _ gap– lock _ x-lock _ next _ key阻止LOCK_S-LOCK_NEXT_KEY死锁处于锁定状态
3.解决方案：经过多方讨论，最终决定用高并发环境下的Replace Into语句替换insetr ON DUPLICATE KEY UPDATE语句来解决死锁问题。
ON DUPLICATE KEY UPDATE语句的作用如下：
如果表中已存在数据的主键值/UNIQUE KEY，请执行更新操作，即更新后的操作。
否则插入新记录。
实现了与Replace Into相同的复检更换功能，避免了高并发死锁问题。
但是，UPDATE操作的性能与DELETE操作相比有一定的性能影响，需要后续的测试随访。