mysql - Mysql自动增加主键ID

Question

我有一些 mysql 表具有自动递增的 id 作为主键，但我注意到我从未真正使用它们......我曾经认为每个表都必须有一个主键，所以我想这就是我之前创建它们的原因。如果我根本不使用它们，我应该将它们全部删除吗？

score 9 · Accepted Answer

除非您遇到空间问题，否则我不会删除它们。

如果您错误地（或疏忽）用重复/错误的数据填充数据库，它们是救生员。

它们还有助于拥有相关表格，您可以通过自动生成的 id 引用一张表格上的内容。

这是假设您有用于实际查询数据的其他列的索引（如果没有，那么有更多理由保留自动增量 ID 并使用它们！）。

score 3 · Accepted Answer

不。

你应该保留它们；数据库总是需要将一行与另一行区分开来的东西（某种“键”）。

如果您有保证每一行都是唯一的东西，那么您可以将其用作键；否则保留主键和自动生成的 ID。

score 2 · Accepted Answer

有趣的！...

我似乎在这里持有少数意见，无论是赞成票还是反对票，目前都是 0，但多数意见中没有人（见上面的回复）似乎对保留 id 字段有很大的理由，而反对票的人没有甚至懒得留下评论暗示为什么取消 id 是个坏主意。

在他们的辩护中，我自己的原始回应没有包含任何强有力的论据，说明为什么在某些情况下可以取消 id 属性（这似乎适用于 OP）。也许这种无端的回应本身就是一个不受欢迎的回应。

请教育我和 OP，通过留下评论赞成或反对_systematic_（我强调“系统性”）需要在所有表中包含自动递增的非语义主键。我回复了一个承诺并添加到我的回复中，以提供一个原因列表，说明为什么它可能不利于 [再次，系统地] 施加自动递增的 PK。

我原来的回答： 你打赌！你可以删除这些！

在对数据库执行任何操作之前，请确保您有备份，尤其是数据库大小非常重要。

使用ALTER TABLE语句删除要删除的表中的 id。具体
是ALTER TABLE myTable DROP COLUMN id（如果表有这样的约束，还需要在移除id之前移除PK约束）

编辑（稍后添加）
在许多情况下，携带自动递增的 ID 键是没有意义的，无论这些键添加的额外存储要求相对较少。
在所有这些情况下，潜在的含义是

数据中“本机”提供的键不一定需要是单列键，它可以是复合键，尽管在这些情况下可能希望更仔细地研究情况，特别是整体键有点长。

以下是使用自动递增主键代替本机或应用程序提供的键的一些缺点：

有效的数据完整性可能未经检查
，即服务器可能允许记录插入创建重复的 [native] 键的更新（尽管人工的、自动递增的主键隐藏了这一现实）
当依靠自动递增的 PK 来支持表之间的连接时，当必须更新部分 [native] 键值时
......我们要么创建完整删除记录的需要，然后重新将其插入新闻值，
...或保留过时/不正确链接的风险。
使用自动递增键的常见“后续操作”是在表上为该键创建聚集索引。这对于没有本机或应用程序提供的主键的表确实有意义，对于具有此类键的数据集来说意义重大。这有效地防止了为聚集索引选择键，这可能对最常见的查询模式更有利。
根据 DBMS，使用自动递增键迁移表可能会变得更加困难（需要在复制之前将基础列声明为纯整数，然后需要重新开始自动递增...）
对于窄表，即只有几列的表，自动递增 PK 的相对成本可能很大，并且以不可忽略的方式影响性能。
在关联表中插入新记录和关联记录时，需要在插入主记录后获取自增键，才能插入关联记录；当支持链接的列值提前知道时，逻辑会更简单。

总而言之，只要存储能够承载人工主键的[相对最小的]额外“重量”，我们就应该包含和使用这样的键，这种想法并非没有其自身的缺陷。

最后一个考虑是，就像当我们不需要这些键时很容易删除它们一样，它们也可以很容易地添加，事后，当/如果它们在特定情况下变得明显有用时。 两种形式的重构（添加与删除自动递增的列）都不是无风险的，但也不是主要生产。

score 2 · Accepted Answer

我会亲自保留它们。如果您以后扩展数据库设计并需要引用此表，它们将特别有用。

score 0 · Accepted Answer

是的，如果你能找出另一个主键。

您的桌子设计显然存在缺陷。例如，您有一个像 relation_id(PK), parent_id, child_id. 已知 parent_id 和 child_id 的组合是唯一的，那么可以将主键赋值为parent_id + child_id，然后删除列relation_id。

应该有无穷无尽的其他可能的情况，但请记住，主键可以帮助您快速定位数据，并帮助您使您的设计有意义。