如果不存在则新增,存在则累加更新某一个字段的值,于是乎就想到了使用insert… on duplicate key update这个语句,但是有一天去测试环境查看错误日志时,却发现了在多个事务并发执行同一条insert…on duplicate key update 语句时,也就是insert的内容相同时,发生 了死锁。
如果将insert on duplicate key update换成insert ignore语句,是否可以避免死锁的发生呢?答案是:否定的。其实原理都是一样的。如果我们将上述复现中的insert on duplicate key update换成insert ignore,同样会在T4时刻出现死锁。 同样,update和insert on duplicate key update组合也可以构造出死锁的出现。数据库中表结构...
同时我们可以证明这时code=3肯定是被排他锁锁住的,由于当出现唯一键冲突时,就会执行on duplicate key update,更新other字段,所以code=3一定在更新结束后处于排它锁锁定状态(补充说明:可以证明如果是共享锁的话,session2在T2时刻执行insert into test2(code, other) values (3, 33)语句的话,一定会立刻包duplicate e...
业务方的目的是使用insert on duplicate key update对重复存在的记录进行更新,没有则插入最新的记录。 另外需要特别注明的是我们最近对数据库进行升级,将数据库版本从Percona的5.6.24升级到5.7.22,业务在老版并没有死锁出现,但是升级到5.7.22版本的RR模式之后出现死锁。 小插曲我们的数据库架构是 app-->rds proxy(...
数据入库这块有离线和实时两套入库系统,写同一个db的同一批mysql表,两边用的都是insert into table on duplicate key update这种方式。实时一直运行,离线5分钟更新一次,当两套系统同时运行时出现了死锁问题,频率还挺高。事务的隔离级别是read committed 读提交。
本文分析了INSERT及其变种(REPLACE/INSERT ON DUPLICATE KEY UPDATE)的几个场景的死锁及如何避免: 场景一:INSERT 唯一键冲突 场景二/三:REPLACE INTO唯一键冲突(来自线上业务) 场景四:INSERT主键冲突(来自官方案例) 其实Google 一番,也会有大量这样的文章。本文只是就几个场景进行了分析,不过一遍走下来,对INSERT加...
并发环境下,执行insert into … on duplicate key update…导致死锁 死锁模拟复现: 事务一执行: mysql>begin;//第一步 Query OK,0rows affected (0.00sec) mysql>insertintosong_rank(songId,weight)values(15,100)onduplicatekeyupdateweight=weight+1;//第二步 ...
本文分析了INSERT及其变种(REPLACE/INSERT ON DUPLICATE KEY UPDATE)的几个场景的死锁及如何避免: 场景一:INSERT 唯一键冲突 场景二/三:REPLACE INTO唯一键冲突(来自线上业务) 场景四:INSERT主键冲突(来自官方案例) 其实Google 一番,也会有大量这样的文章。本文只是就几个场景进行了分析,不过一遍走下来,对INSERT加...
如果已经存在了则更新它如果更新日期或者某些列上的累加操作等,我们肯定会想到使用INSERT ... ON DUPLICATE KEY UPDATE语句,一条语句就搞定了查询是否存在和插入或者更新这几个步骤,但是使用这条语句在msyql的innodb5.0以上版本有很多的陷阱,即有可能导致death lock死锁也有可能导致主从模式下的replication产生数据不一致...
然后看到这篇INSERT ... ON DUPLICATE KEY UPDATE产生death lock死锁原理,发现这应该是这个版本的bug 所以还是需要减少这类语句的使用。 不过我在新安装的MySQL8.0上重新走了以上步骤,是没有问题的。 关于锁比较全的博客: Mysql Innodb 中的锁 0人点赞 ...