Mysql自动增加主键ID答案

【问题标题】：Mysql auto increment primary key id'sMysql自动增加主键ID
【发布时间】：2010-12-09 15:25:18
【问题描述】：

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

【问题讨论】：

【解决方案1】：

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

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

它们还有助于创建相关表格，您可以在其中通过自动生成的 id 引用一个表格上的内容。

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

【讨论】：

如果他根本不使用这些键，那么数据库设计中肯定存在缺陷。
除非他始终正确地使用自然键。但是，是的，当我读到这个问题时，我也是这么想的。
通常这些自动生成的 id 是您用来建立表之间关系的。这样，行中的任何其他内容都可以更改，并且关系保持不变。我同意混沌。
-“如果您不小心（或疏忽）用重复/错误的数据填充数据库，它们可以挽救生命。”是真的，没想到。 -“它们还有助于拥有相关的表格，您可以通过自动生成的 id 引用一张表格上的内容。”你这是什么意思？
“如果他根本不使用这些密钥，那么数据库设计中肯定存在缺陷。” -例如，我有一张带有评级的表格。我有一个评级 ID 的自动增量 PK。我从来没有真正使用过这个id...我永远不会加入任何带有这个id的表，我的查询也不需要使用这个id。有什么问题吗？

【解决方案2】：

有趣！...

我似乎在这里持有少数意见，upvoted 和 downvoted 目前都为 0，但没有一个占多数意见（请参阅上面的回复）似乎保留了 id 字段，并且反对者甚至没有费心让 cmets 暗示为什么取消 id 是一个坏主意。

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

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

我的原始回复： 你打赌！你可以删除这些！

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

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

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

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

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

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

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

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

【讨论】：

我同意你所说的，如果我以后确实需要PK，我可以生成列。保持 PK 对我来说很突出的一点是，“如果你错误地（或疏忽）用重复/错误的数据填充数据库，它们是救命稻草。”尽管我认为这种可能性对我来说很少见。相反，我更有可能不小心丢弃整张桌子，这是我以前做过的。 :p
@Roger：即使没有 PK，也有很多方法可以删除意外添加的重复行（和/或从当前状态重新创建表）。此外，关于意外行的论点可以另辟蹊径：使用语义驱动的 PK 约束，首先不会发生重复的行；-) 我是自动递增 PK 的频繁用户/从业者，但我想要你知道这没关系，确实建议在某些情况下取消这些。
我的论点可能比它应该的措辞更强烈，因为我对其他回应的片面性作出反应，以及对一个远非错误的回应投反对票的不公平性......
是的，没问题。我认为人们实际上误解了我的问题。正如我在开篇文章中所述，我只是没有将 PK 用于我的“某些”表。在这些表中，我当然想删除并非所有表的 PK。

【解决方案3】：

没有。

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

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

【讨论】：

【解决方案4】：

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

【讨论】：

【解决方案5】：

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

显然你的桌子设计有缺陷。例如，你有一张像 relation_id(PK), parent_id, child_id 。已知parent_id和child_id的组合是唯一的，那么可以将主键赋值为parent_id + child_id，然后去掉列relation_id。

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

【讨论】：