除了这些好答案，我想分享一篇我刚读过的好文章，伟大的主键辩论。

这里引用几点:

开发人员在为每个表选择主键时必须应用一些规则:

主键必须唯一地标识每条记录。 记录的主键值不能为空。 在创建记录时，主键-值必须存在。 主键必须保持稳定—您不能更改主键字段。 主键必须紧凑且包含尽可能少的属性。 主键值不能更改。

自然键(倾向于)打破规则。代理键符合规则。(你最好通读那篇文章，它值得你花时间!)

以下是我拥有25年以上开发经验后得出的经验法则。

所有表都应该有一个单列主键auto 增量。 将它包含在任何意味着可更新的视图中 主键在应用程序上下文中不应该有任何意义。这意味着它不应该是SKU、帐号、员工id或对应用程序有意义的任何其他信息。它只是一个与实体相关联的唯一键。

主键由数据库用于优化目的，应用程序除了用于标识特定实体或与特定实体相关外，不应该使用主键。

始终使用单一值主键使得执行upsert非常简单。

Favor multiple indices on single columns over multi-column indices. For example, if you have a two column key, favor creating an index on each column over creating a two column index. If we create a multi-column key on firstname + lastname, we can't do indexed lookups on lastname without providing a firstname as well. Having indices on both columns allows the optimizer to perform indexed lookups on either or both columns regardless of how they are expressed in your WHERE clause. If your tables are massive, explore partitioning the table into segments based on the most prominent search criteria. If you have a table that has a significant number of Id fields in it, consider removing all except the primary key to a single table which has an id (PK), an org_id (FK to original table) and an id_type column. Create indices for all columns on the new table and relate it to the original table. In this manner, you can now perform indexed lookups of any number of ids using only a single index.

所有表都应该有一个主键。否则，您所拥有的就是一个HEAP——在某些情况下，这可能就是您想要的(当数据通过服务代理复制到另一个数据库或表时，会产生大量插入负载)。

对于行数较少的查找表，可以使用3 CHAR代码作为主键，因为这比INT占用的空间更少，但性能差异可以忽略不计。除此之外，我总是使用INT，除非您有一个引用表，它可能有一个由相关表的外键组成的复合主键。

自然键和人工键是数据库社区中的一种宗教争论——请参阅本文及其链接的其他文章。我既不赞成一直使用人工钥匙，也不赞成永远不使用。我会根据具体情况做出决定，例如:

美国各州:我会使用state_code(德克萨斯州的'TX'等)，而不是德克萨斯州的state_id=1 员工:我通常会创建一个人工的employee_id，因为很难找到其他任何工作。SSN或同等的工作，但可能会有问题，如新加入谁还没有提供他/她的SSN。 员工薪资历史:(employee_id, start_date)。我不会创建一个人工的employee_salary_history_id。它能起到什么作用(除了“愚蠢的一致性”)

无论在哪里使用人工键，都应该始终在自然键上声明唯一的约束。例如，如果你必须使用state_id，但是你最好在state_code上声明一个唯一的约束，否则你最终肯定会得到:

state_id    state_code   state_name
137         TX           Texas
...         ...          ...
249         TX           Texas

您应该使用由多个字段组成的“复合”或“复合”主键。

这是一个完全可以接受的解决方案，点击这里了解更多信息:)

我将坦率地说明我对自然键的偏好——在可能的情况下使用它们，因为它们将使您的数据库管理工作更加容易。我在公司建立了一个标准，所有的表格都有以下列:

行ID (GUID) 创造者(字符串;有一个默认的当前用户名(SUSER_SNAME()在T-SQL)) 创建(DateTime) 时间戳

行ID在每个表上都有一个唯一的键，并且在任何情况下都是每行自动生成的(并且权限阻止任何人编辑它)，并且合理地保证在所有表和数据库中是唯一的。如果任何ORM系统都需要一个ID密钥，那么可以使用这个密钥。

同时，如果可能的话，实际的PK是一个自然的关键。我的内部规则是这样的:

人-使用代理键，例如INT。如果它是内部的，那么Active Directory用户GUID是一个可以接受的选择 查找表(例如StatusCodes) -使用短的CHAR代码;它比int更容易记住，在许多情况下，纸张表格和用户也会使用它来简洁(例如，Status = "E"表示"过期"，"A"表示"已批准"，"NADIS"表示"样品中未检测到石棉")。 链接表- fk的组合(例如EventId, AttendeeId)

因此，理想情况下，您最终会得到一个自然的、人类可读的和难忘的PK，以及一个orm友好的每个表一个id的GUID。

警告:我维护的数据库倾向于100,000条记录，而不是数百万或数十亿条记录，所以如果您有使用大型系统的经验，这不利于我的建议，请随意忽略我!