Mysql自动增加主键id

Question

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

Answer 1

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

如果您错误地（或疏忽）使用重复/错误数据填充数据库，它们可以节省生命。

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

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

Answer 2

没有。

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

如果您确保每行都有一些独特的东西，那么您可以将其用作关键字;否则保留主键和自动生成的ID。

Answer 3

有趣！...

我似乎在这里持有一个少数意见，让赞成和 downvoted 到目前的偶数0，但大多数人都没有意见（见上面的回应）似乎使保持id字段的大部分情况，并且downvoters甚至没有留下评论暗示为什么取消id这是一个坏主意。

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

请教我和OP，通过留下评论赞成或反对 _systematic _ （我强调“系统”）需要在所有表中包含自动递增的非语义主键。答应我回来并添加到我的回复中，提供一个原因列表，列出为什么它可能对[再次，系统地]施加自动递增的PK有害。

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

在对数据库执行任何操作之前，请确保您有备份，特别是数据库大小很重要。

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

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

• 数据本身提供主键
• 或者，应用程序管理密钥生成

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

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

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

总而言之，只要存储能够承载人工主键的[相对最小]额外“权重”，我们应该包含并使用这样的密钥，这并不是没有自己的缺点。

最后一个考虑因素就是当我们不需要它们时很容易删除这些键，它们也可以很容易地添加，事后，当它/如果显然它们在某个特定用途中有用时情况。 这两种形式的重构（添加与删除自动增加的列）都没有风险，但也不是主要产品。

Answer 4

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

Answer 5

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

你的桌子设计显然存在缺陷。例如，你有一个像这样的表 relation_id(PK), parent_id, child_id。 众所周知，parent_id和child_id的组合是唯一的，然后您可以将主键指定为parent_id + child_id，然后删除列relation_id。

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