MySQL:8.0.31-使用几个月后ID字段出现大缺口(数千)

我们在多个表中看到mysql 8.0.31发行版中auto_increment的主键列中有很大的缺口(默认为-innodb_autoinc_lock_mode=2(交错锁模式))。此外,我知道在这种模式下可能会出现一些较小的差距。

我们有'order'表(id bigint)和'order_line_items'表(id bigint)。

TABLE_NAME          | CURRENT AUTO_INCREMENT    |  TABLE ROW COUNT
order               |   27504                   |        1367
order_line_items    |  430930                   |       34970

我们共有1367个订单行,当前自动增量值为'27504',34970个(订单行项目行),当前自动增值值为'430930'。我们在API调用中将、order和order_line_items都保存在同一个事务中(可能会出现错误,导致事务回滚)。

差距:

一旦我们注意到订单表缺口持续了1-2天,并从今天起再次增加“1”。跳跃在集群中连续发生(检查下面),并返回递增“1”。

Order table gap details:

id    |  difference from previous 'id'
-------------------------------------
27489   1
27488   1
27487   1
27486   232
27254   232
27022   693
26329   240
26089   401
25688   175
25513   348
25165   864
24301   7656
16645   1709
14936   184
14752   13
14739   541
14198   82
14116   215
13901   68
13833   117
13716   140
....
1468    1
1467    10
1457    1
1456    1
1455    1
1454    9
1445    1
1444    1
1443    1
1442    1
1441    1

观察结果:

我们使用(OpenJPA)为Id使用配置(@Id,@GeneratedValue(策略=GenerationType.IDENTITY)。代码中没有设置Id。
我们在其他表格中也看到了同样的模式。我们测试了相同的API,使用20个线程并行创建相同的API,但这两个表的创建id没有类似的大差距。
直到订单表中的id:1445(我们有1225行的计数),我们没有看到更大的跳跃有任何问题。在id:1445之后,我们开始看到订单表中的多次跳跃,直到27487,连续1-2天。
我还了解到,在API调用中回滚事务可以增加自动增加值,但与总记录相比,出现多个更大的跳跃似乎是不可理解的。

问题:

有人知道这是什么原因吗?。当顺序表中的总记录低于1367条时,为什么id会跳到数千条(例如,上例中的76561709条)?。
我看到这种情况发生在多个id岛的集群中,并开始一个接一个地创建(就像上面的例子)。这与mysql数据相关进程的任何其他内部处理有关吗?。这可能是mysql中的错误吗?
是什么导致“mysql”像这样跳得更高(例如,大容量插入,共享锁会导致这种情况吗)?。如何在本地模拟此问题?。

任何想法都会很有帮助。

更新: 多个API调用已完成,但由于客户端的意外重试,导致API级别的调用失败,导致ID中出现较大间隙。谢谢大家。