标识栏重新设置种子：何时需要？

在大学的最后一课中（我是学生），讲师要求我们开发数据库（如果重要的话，请使用MySQL Server）和小型客户端应用程序，该应用程序会将数据库用作数据源。

要求之一是，身份列（每个表中的PK）必须是顺序的，因为这是一种好习惯（按照讲师的话）。也就是说，当删除表行时，必须在后续插入中重用它的PK。我对RDBMS，PK和标识列有一般的了解。据我了解，标识列只是让数据库在插入行时自动生成PK的一种方式。标识列值不得以任何方式与行属性相关（只要它不是自然键即可）。

这个要求（严格按照顺序标识列）对我来说是可疑的。我试图问讲师，如果身份不是顺序的（由于删除引起的空白），那又有什么问题，但是却得到了非常抽象的答案，例如“它对用户方便，对维护数据库的数据库管理员有用”。没有具体的例子。“方便用户”这一说法听起来很愚蠢，因为它在业务领域没有任何意义。

因此，我很好奇这些原因是否真实？我只想到一种情况，即需要重新分配标识列种子时–当标识空间用尽时。但是，当标识列类型选择不正确时，例如用“ simple” int代替，bigint或者uniqueidentifier表包含十亿行时，这将是更多的设计问题。假设身份列是聚集索引：身份列中的间隙会影响索引性能吗？也许还有其他现实原因导致我不知道的每次删除后重新自动标识列的种子？

提前致谢！

也就是说，当删除表行时，必须在后续插入中重用它的PK。

您的讲师来自哪个宇宙？

那是非常低效的。如果您尝试这样做，则会将性能预期降低10倍。

如果出于审计的原因需要无间断的数字，请显式地构建它们，而不是直接从数据库工具中构建它们。并且永远不会删除行，而是将其标记为“已删除”。这将增加查询的混乱程度，因为它们将不得不忽略此类行。

在MySQL中，InnoDB要求PRIMARY KEY每个表都具有唯一性。但这就是要求的程度。键甚至可以是字符串。

差距为用户和DBA 带来了便利，而不是带来不便。

我可以想到一种情况，无间隙会很方便-一次分块为100行。但是有一个简单的解决方法LIMIT 100,1。

间隙对性能的影响为零。包括非数字索引。和非唯一索引。和复合索引。

当然，您可以用完ID。我想我已经在使用MySQL的近20年中看到了两次。我还担心被小行星撞击。这在我夜间保持清醒的事情上很低。

间隙从（至少）发生： INSERT IGNORE，IODKU，REPLACE，DELETE，ROLLBACK（显式的，或由于崩溃），多主复制（包括加莱拉和组复制）。您是否真的想针对这些问题提出解决方法？

随时让我们理智地检查讲师说的其他可疑事项。

通常不建议重用标识值。该值要么完全在内部使用，在这种情况下，它的实际值是无关紧要的，要么在外部使用，在这种情况下，重用该值很可能会导致错误识别。

以发票或采购订单号的明显情况为例，它们可能很容易来自标识列并在外部公开，但是由于这个原因，您永远都不想重复使用它们。两者都指的是您不希望混淆的特定交易。

当公司合并或被收购时，解决这些问题可能是一个很大的麻烦。故意制造此类问题？不明智。

PK id值的重用存在问题，通常应避免。

首先，auto_increment列的实现不能保证无缝。如果回滚自动增量列上的插入，确实会出现间隙。

其次，空位ID可能引用尚未删除的现有数据（由于缺少FK约束）。如果将其转换为在系统外部通信的会员编号，则将构成潜在的业务标识风险。

第三，bigint unsigned即使插入率非常高，ID也不会在相当长的时间内用完。

差距最大的痛苦来自坚持坚持其审计缺陷的审计师。对于DBA，他们知道差距存在以及原因。

我不会回应其他人的评论，即重用PK是个坏主意，但我遇到过需要重新种植身份列的情况。

PK索引本身已损坏。

当然，这是使用MS-SQL进行的，很多年前，但这仍然很重要。很多年前，对于我工作的公司来说，有人认为，将PC用作服务器的旧设备以至于无法被客户使用，然后将其粘在壁橱中，将PC用作服务器是一个好主意。没有通风。何时不这样做因为我们都知道，在一小间房间里运行120多个关键任务数据库的小房间里，一堆破旧的10年旧计算机只会带来好结果。就像40％的失败率，我重新思考了自己的职业选择。我们会将数据复制回公司总部，但更多的是，这些故障会导致数据库发生不良情况。其中之一是数据库索引损坏，这将占用数据库和复制过程。在这种出色的环境中，两次修复复制的唯一解决方案是重新设定索引的种子，然后重新建立复制。稍后我们确实替换了服务器，然后完全放弃了它们。