MySQL 跳过 auto_increment 值（续）

Question

我想继续下面的精彩讨论，因为我仍然不明白发生了什么。 我使用谷歌云 MySQL

innodb_version  5.7.25
innodb_autoinc_lock_mode    1

我将记录上传到由自动递增主键作为键的表中。 没有其他唯一键。 我是唯一的用户，我是单线程的。 我注意到密钥中的零星空白与此线程上其他人报告的空白相似。

为了试验这些东西，我使用了我批量上传的 5 个 CSV 文件；在每次实验批次运行后，我删除了表并重新创建了它。我每次都以相同的顺序上传了所有 5 个文件。我尝试了不同的表结构，不同的数据。

在手册中，https://dev.mysql.com/doc/refman/8.0/en/innodb-auto-increment-handling.html 提到了“连续”锁定模式：

此锁定模式可确保在存在预先不知道行数的 INSERT 语句（以及在语句进行时分配自动递增编号）的情况下，所有由任何“类似 INSERT”的语句都是连续的，并且操作对于基于语句的复制是安全的。

我同意，记录是连续的在同一个上传文件中。 但上传之间存在差距。差距各不相同。一个表每次跳过 1 个键，然后停止跳过一段时间，然后再次开始跳过。另一个表每次跳过 8 条记录，这恰好是我在该表看到的第一个 CSV 文件中上传的记录数。

我看不出跳过记录数量的任何韵律或原因，但奇怪的是，每次我重新运行实验批次时都会发生确切的跳过顺序（所以它是一台计算机！）

我阅读了建议的解决方案（将锁定设置为“旧”0；不要使用自动增量；等等）这些都很好，但我确实想使用自动增量，但这种不可预测性让我感到紧张。有谁知道

1. 引擎进行什么计算来确定要“保留”多少键？
2. 在上传开始之前，这种“预订”何时发生？
3. 加载数据是否比 Python 程序更容易出现“密钥浪费”？
4. 有没有办法通过信息、表格结构影响此预订？

非常感谢！

Answer 1

有几种东西可以“烧毁” auto_inc id。你只提到了其中一些。以下是部分列表：

• 在另一列重复
• 服务器崩溃
• 死锁
• ROLLBACK - 明确的或由于某些外力。在每个 SQL 语句后检查错误。
• DELETE -- 因此REPLACE
• INSERT IGNORE
• ALTER ... AUTO_INCREMENT=..
• （也许更多）

（我需要查看有关您的 SQL 的详细信息才能进一步讨论。）

最好不要依赖 auto_inc 是无间隙的。