mysql 并发insert_MySQL RC级别下并发insert锁超时问题 - 案例验证

作者：网易数据库团队

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

第二篇链接：

我们举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中，所以也需要更新该索引，也是走delete+insert。此时detail7_1就存在2条n_u