on duplicate key update性能问题_MySQL RC级别下并发insert锁超时问题 - 案例验证

最新推荐文章于 2024-07-16 10:22:59 发布

呦鱼儿

最新推荐文章于 2024-07-16 10:22:59 发布

阅读量3k

点赞数

文章标签： on duplicate key update性能问题

本文链接：https://blog.csdn.net/weixin_31766871/article/details/113089949

版权

本文探讨了在MySQL RC（Repeatable Read）隔离级别下，使用`on duplicate key update`时遇到的性能问题，特别是二级唯一索引和主键索引场景中的并发insert锁超时现象。通过实例分析，揭示了在更新导致的delete+insert过程中，如何产生锁冲突和超时，同时提出了存在的疑问：为什么在唯一性冲突检查时加的是共享锁而非no gap锁。

摘要由CSDN通过智能技术生成

作者：网易数据库团队

DDB（网易杭研自研的MySQL数据库中间件产品）团队小伙伴发现了一个问题，觉得比较奇怪。于是找到我们，希望解释下。过程中除解释了问题的现象，也通过代码了解了更多的InnoDB DML执行逻辑，还发现了MySQL/InnoDB官方在二级唯一索引冲突检查时加锁行为的反复。本系列打算用三四篇文章来聊聊这个事情。这是第三篇，用实际案例来证明假设。

第二篇链接：

MySQL RC级别下并发insert锁超时问题 - 源码分析

我们举update为例，因为update可以转化为delete+insert，所以也就包含了insert的场景。仍然采用前述的表dt和其中的9条记录。

二级唯一索引场景

我们尝试对id为6的记录做2次update，并在第二次的时候gdb跟踪detail7_1的唯一性约束检查流程。

session1-ddb>begin;
Query OK, 0 rows affected (0.00 sec)

session1-ddb>update dt set id = 66 where id = 6;
Query OK, 1 row affected (6 min 3.98 sec)
Rows matched: 1  Changed: 1  Warnings: 0

session1-ddb>update dt set id = 666 where id = 66;

第一个update将主键id为6的记录更新为66，按照代码逻辑，由于修改了n_uniq字段，所以会走delete+insert，而detail7_1由于主键id在其n_fields