mysql - 为什么我们应该在用户表中有一个 ID 列？

Question

很明显，我们已经有了每个用户的另一个唯一信息，那就是用户名。那么，为什么我们需要为每个用户提供另一个独特的东西呢？为什么我们还应该为每个用户分配一个 ID？如果我们省略 id 列会发生什么？

Answer 1

即使您的用户名是唯一的，使用额外的 id 列而不是使用 varchar 作为主键也没有什么好处。

• 有些人喜欢使用整数列作为主键，作为永远不需要更改的代理键，即使其他列可能会发生变化。尽管自然主键也无法更改，但您必须使用级联外键约束来确保相关表中的外键与任何此类更改同步更新。

• 主键是 32 位整数而不是 varchar 可以节省空间。在引用您的用户表的所有其他表中选择 int 或 varchar 外键列可能是一个很好的理由。

• 如果将新行添加到索引的末尾，与将它们楔入索引的中间相比，插入主键索引会更有效一些。 MySQL 表中的索引通常是 B+Tree 数据结构，您可以研究它们以了解它们的性能。

• 一些应用程序框架更喜欢这样的约定，即数据库中的每个表都有一个名为 id 的主键列，而不是使用自然键或复合键。遵循这样的约定可以使某些编程任务更简单。

这些问题都不会破坏交易。使用自然键也有好处:

• 如果按用户名查找行的次数多于按 id 搜索，最好选择用户名作为主键，并利用 InnoDB 的索引组织存储。如果可能的话，让你的主查找列成为主键，因为主键查找在 InnoDB 中更有效(你应该在 MySQL 中使用 InnoDB)。

• 正如您所注意到的，如果您已经对用户名设置了唯一约束，那么保留一个不需要的额外 id 列似乎会浪费存储空间。

• 使用自然键意味着外键包含人类可读的值，而不是任意整数 id。这允许查询使用外键值，而不必连接回父表以获得“真实”值。

关键是没有涵盖 100% 情况的规则。我经常建议您应该保持选择开放，即使在单个数据库中也应使用自然键、复合键和代理键。

我在我的书 SQL Antipatterns Volume 1: Avoiding the Pitfalls of Database Programming 的“需要 ID”一章中介绍了代理键的一些问题.