在大学的最后一堂课中（我是学生），讲师要求我们开发一个数据库（如果重要，可以使用 MySQL 服务器）和将数据库用作数据源的微型客户端应用程序。
要求之一是标识列（即每个表中的 PK）必须是连续的，因为这是一种很好的做法（根据讲师的话）。即当删除表行时，它的 PK 必须在后续插入中重复使用。我在 RDBMS、PK 和身份列方面具有平均知识。据我了解，该标识列只是让数据库在插入行时自动生成 PK 的一种方式，仅此而已。并且标识列值不应以任何方式与行属性相关（只要它不是自然键）。
这个要求（严格的顺序标识列）对我来说很可疑。我试图问讲师，如果身份不是顺序的（由于删除导致的间隙），有什么问题，但得到了非常抽象的答案，例如“这对用户来说很方便，对维护数据库的数据库管理员很有用”。没有具体的例子。“方便用户”的说法听起来很愚蠢，因为它在业务领域没有任何意义。
因此，我很好奇这些原因是否真实？我只能想到一种需要重新设置标识列的情况——当标识空间耗尽时。但是，当标识列类型选择不正确时，这是更多的设计问题，比如简单int而不是bigint表uniqueidentifier包含十亿行时。假设一个标识列是一个聚集索引：标识列中的间隙会影响索引性能吗？也许在我不知道的每次删除后自动标识列重新播种的其他现实原因？
提前致谢！
你的讲师来自哪个宇宙？？
这是非常低效的。如果您尝试这样做，您的绩效前景将减少 10 倍。
如果出于审计原因需要无缝数字，请明确构建它们，而不是直接从数据库工具中构建。并且永远不要删除行，而是将它们标记为“已删除”。这将增加查询的混乱，因为他们将不得不忽略这些行。
PRIMARY KEY在 MySQL 中，InnoDB 要求每个表都存在唯一性。但这就是要求的程度。键甚至可以是字符串。差距对用户和 DBA 来说是一种便利，而不是一种不便。
我可以想到一种无间隙会很方便的情况——一次分成 100 行的组。但是有一个简单的解决方法，使用
LIMIT 100,1.差距对性能的影响为零。这包括非数字索引。和非唯一索引。和综合指数。
当然，您可能会用完 id。我想我在使用 MySQL 的近 2 年中已经看到过两次这种情况。我还不如担心被小行星撞击。它在我的让我保持清醒的事情清单上很低。
差距发生在（至少）：、、、、、 （显式或由于崩溃）、多主复制（包括 Galera 和组复制
INSERT IGNORE）。你真的想为那些想出解决方法吗？！IODKUREPLACEDELETEROLLBACK随意让我们理智地检查讲师所说的任何其他可疑之处。
通常不鼓励重用标识值。要么该值完全在内部使用，在这种情况下它的实际值无关紧要，要么它也用于外部，在这种情况下重用该值很可能会导致错误识别。
以发票或采购订单号为例，它们可能很容易来自标识列并暴露在外部，但正是出于这个原因，您永远不想重复使用它们。两者都指您不想混淆的特定交易。
当公司合并或被收购时，解决此类问题可能会很麻烦。故意制造这样的问题？不明智。
PK id 值的重用存在问题，通常应避免。
首先，auto_increment 列的实现并不能保证无间隙。如果您回滚自动增量列上的插入，确实会出现间隙。
其次，间隙 ID 可能指的是尚未删除的现有数据（由于缺少 FK 约束）。如果它们转化为在系统外传达的会员编号，那么这会带来潜在的商业身份风险。
第三，
bigint unsigned即使插入率非常大，也不会在很长一段时间内用完 ID。差距最大的痛苦是遇到坚持认为这是一个审计缺陷的审计师。对于 DBA，他们知道存在差距及其原因。
我不会回应其他所有人的评论，即重复使用 PK 是一个坏主意，但我遇到过需要重新播种身份列的时候。
PK 指数本身的腐败。
当然，这是在很多很多年前使用 MS-SQL，但它仍然是相关的。许多年前，对于我工作的公司，有人认为在我们的 150 多个远程位置重新使用 PC 作为服务器是一个好主意，因为它们太旧而不能被客户使用，然后将它们放在壁橱里没有通风。什么时候没有因为我们都知道，在一个运行着 120 多个运行关键任务数据库的小房间里，一堆 10 年的旧计算机只会带来好事。就像 40% 的失败率和我重新考虑我的职业选择一样。我们会将数据复制回公司总部，但通常情况下，这些故障会导致数据库发生坏事。其中之一是数据库具有损坏的索引，这将占用数据库和复制过程。在这个伟大的环境中两次，修复复制的唯一解决方案是重新设定索引，然后重新建立复制。我们后来确实更换了服务器，然后完全放弃了它们。