设置基本表，整数自增主键是标准吗？答案

【问题标题】：Setting up a basic table, is integer auto-increment primary key a standard?设置基本表，整数自增主键是标准吗？
【发布时间】：2011-06-23 17:01:54
【问题描述】：

我有一个网络应用程序，我有一个用户概念，它可能会进入一个用户表，例如：

table: user
username (varchar 32)  |  email (varchar 64)  |  fav_color  |  ...

我希望用户名和电子邮件是唯一的，这意味着我不能允许用户拥有相同的用户名或相同的电子邮件。我看到这种类型的示例表总是引入一个整数自增主键。

不知道为什么要这样做，是不是为了以后通过外键加快查询速度？例如，假设我有另一个表，例如：

table: grades
username (foreign key?)  |  grade

使用用户名作为外键是否效率低下？我想做如下查询：

SELECT FROM grades WHERE username = 'john'

所以我想对数据库进行整数查找会更快？：

SELECT FROM grades WHERE fk_user_id = 20431

谢谢

【问题讨论】：

【解决方案1】：

我的建议，经过多年的数据库建设

仅在不代表现实世界中的任何内容时将字符用作 PK。

现实世界是一片混乱的地方，一旦你使用它的PK，你就是一个斜坡。

相信我。

（还有速度增益）。

问候， //t

【讨论】：

【解决方案2】：

它本身可能不一定是“标准”，但它快速、简单、方便并且通常可以抵抗业务密钥更改。

【讨论】：

【解决方案3】：

整数列上的索引比大字符值上的执行速度更快。将主键放在窄标识列上是最佳解决方案。

【讨论】：

【解决方案4】：

随着应用程序的发展，整数作为主键将使您的生活更加轻松。使用您的用户名和/或电子邮件上的索引进行查询优化。

【讨论】：

【解决方案5】：

我喜欢整数键，因为：

【讨论】：

【解决方案6】：

您所问的问题在某种程度上是基于个人数据建模者判断的设计决策。就个人而言，在这种情况下，我会包含自动递增的整数主键。能够保证用户名（尤其是电子邮件地址）不变是不寻常的。但是，您可以设计您的软件，使相同的整数主键始终指向相同的用户，而不管该用户记录可能发生的其他变化。

有助于提高用户名查找性能的是用户名的唯一约束，其索引对应于它。如果您真的希望电子邮件地址是唯一的（主要是业务需求决定），您还可以对电子邮件地址设置一个 UNIQUE 约束。 MySQL 的默认数据库引擎中忽略了外键（不幸的是），因此我不会费心从数据建模的角度探讨其中的好处。

编辑：

如果现在强制执行外键，我想我会探讨外键的好处。是的，有更新依赖于外键的所有数据的规定（例如 ON UPDATE CASCADE）。然而，它们通常很难被理解并且被认为难以维护。让外键引用不变的东西通常是更好的做法，因此您的整数主键。

【讨论】：

【解决方案7】：

使用真实世界的数据作为外键是非常成问题的，而且“效率低下”，因为它们违反了参照完整性。您认为用户名和电子邮件是独一无二的并且永远不会改变吗？你几乎肯定是错的。阅读natural keys上的早期问题

整数自动增量主键会更快，但这不是使用它们的原因。它们被使用是因为它们有效。使用它们。

【讨论】：

“真实世界”数据作为外键不会违反参照完整性。毕竟，外键约束的目的是确保 RI 不能被违反。也许您的意思是您可能需要一些不在被引用表中的键值，但是无论您使用什么键，这种情况都是完全相同的。同样，您将对自然键创建一个约束，因为确保电子邮件（或其他）的唯一性对您的数据模型和您的业务很重要——例如，作为用户帐户的唯一登录名。
不幸的是，在现实世界中，“自然键”违反了您需要的约束。它们既不独特也不持久。
您可以在数据库中使用与实际相同的识别方案。否则，您的数据库将不准确地代表该现实。实际上，不同的事物总是可以唯一识别的。无论如何，您所说的是“真正的”密钥违反了 RI，这肯定是不真实的，这就是我想指出的。