Database 所有数据库表都应该有主键吗？

给每个数据库表一个主键是一种好的做法吗？在我看来，如果主键不是显式需要的，那么它只会在我的数据库中造成额外的混乱

当你可能会： 在OLTP数据库中，您几乎总是（在我的情况下总是）有某种主键。有时是Guid，有时是自动编号/标识字段，有时是由应用程序或客户设置的。有时甚至是多个字段的组合。这是因为您通常希望唯一地标识表中的任何给定行

此外，主键是查询优化程序使用的约束，它可以提高查找和连接的性能

当你可能不会：

---

唯一没有主键的时候是在“报告”表中，可能是在非规范化的数据仓库中。

通常是的-我会对仅为报告目的存储的“真实”数据的汇总版本的表（即为报告/性能原因创建的汇总表）进行例外，但一般来说，我总是有一个主键——在我的应用程序中，它几乎总是一个自动递增的整数，相对于行大小几乎不需要额外的空间。

虽然主键非常有用（我一直在使用它们），但让我们明确一点，如果你不需要主键，就不需要创建主键。有些情况下您不需要一个，其中包括：

• 一个表，它只收集要查询的数据（出于持久性目的），而不与其他表相关，在这些表中，其他表需要查找与之相关的精确行
• 您不需要在表中强制任何类型的唯一性

---

在上述两种情况下，您可能只对表的聚合信息感兴趣，而不是唯一地标识行。我相信还有其他的。但不使用主键是可以的——这就是为什么在创建表时（在大多数系统中）不需要主键的原因。

这不是必需的，但请确保您永远不需要主键。主键的用途是，您可以根据一组（通常是最小的）条件从一行到另一行。这允许数据库确保您没有重复的数据，例如，这也允许您的数据库符合。如果这不是必需的，那么您不需要主键，但首先要仔细考虑它

---

不要忘记，主键不一定是包含任意唯一值的附加列—它也可以是一组列，共同定义唯一性（例如，地址簿表中的一个人的名字、姓氏和出生日期）

是的，在每个表上都有一个主键是很好的做法

但是，不是每个表都应该有一个自动编号id列。我觉得有必要详细说明这一点，因为出于某种原因，很多人倾向于在所有表格中都添加一个额外的ID，即使已经存在一个非常好的候选人。例如，表示

用户组的多对多表应使用
{user\u id，group\u id}

除了在门口停止重复，主键约束还携带优化器在生成执行计划时使用的信息

这就是为什么我总是，或者至少很少有例外，在我创建的所有表上都有一个主键。
事实上，我甚至在报告表上创建了主键，其中大多数列都是主键的一部分。因为在开发过程中，由于我做错了什么，我至少会遇到一个唯一的约束冲突。如果有大量的数据并且没有约束，我就不会发现错误。
关系数据库设计中的键的目的是防止重复数据，从而帮助确保数据的完整性。如果允许重复行，则会产生歧义、潜在的更新异常以及极有可能不正确的结果。因此，一般来说，每个表都应该至少有一个键（如果需要，可能有多个键）。通常情况下，数据完整性不是“明确需要的”

主键只是表的任意一个键。指定一个键作为主键可能很有用，但并不特别重要——重要的是每个表至少有一个候选键

数据库文献中广泛地讨论了避免重复行的原因。见：




我有一个由CreateDate分区的表，它不是唯一的。在我的例子中，我决定从此表中删除主键，因为主键索引必须是唯一的这一事实意味着我不能将此索引设为本地索引，而必须是全局索引。这意味着从该表中删除任何内容（以及其他操作）都会使该主键索引不可用，使其变得无用。
为什么要在表中复制数据？您想要查询表这一事实意味着您想要知道每一行代表什么。如果您没有密钥，则您不知道-例如，它可能是每（x）、（y）或（x、y、z）一行，有效使用数据几乎是不可能的。不是这样，您可能只是对聚合信息（总和、计数等）感兴趣。问问自己为什么DB系统不需要主键约束。我不是说主键没有多大用处——我一直在使用它们，但这不是问题所在。试着打开你的大脑一分钟，考虑到你可能只是想把数据集中在你想要分析它的集合中，而不把它与你的数据库系统中的其他数据联系起来（尽管你可能想把聚合结果联系起来）。我已经编辑了我原来的回答——我想我是被认为太自由了（我的错误）。我绝对相信并经常使用主键（因为它们是有意义的）。我的主要观点是，有些用例