虽然来晚了，但我想补充一下我的观点:

每个表都应该有一个主键吗?

If you are talking about "Relational Albegra", the answer is Yes. Modelling data this way requires the entities and tables to have a primary key. The problem with relational algebra (apart from the fact there are like 20 different, mismatching flavors of it), is that it only exists on paper. You can't build real world applications using relational algebra. Now, if you are talking about databases from real world apps, they partially/mostly adhere to the relational algebra, by taking the best of it and by overlooking other parts of it. Also, database engines offer massive non-relational functionality nowadays (it's 2020 now). So in this case the answer is No. In any case, 99.9% of my real world tables have a primary key, but there are justifiable exceptions. Case in point: event/log tables (multiple indexes, but not a single key in sight).

总之，在遵循实体/关系模型的事务应用程序中，为几乎(如果不是)所有表设置主键非常有意义。如果您决定跳过表的主键，请确保您有一个很好的理由，并准备为您的决定辩护。

我想找到一些官方的东西像这样- 15.6.2.1集群和次要索引- MySQL。

如果表没有PRIMARY KEY或合适的UNIQUE索引，InnoDB内部会在一个包含行ID值的合成列上生成一个名为GEN_CLUST_INDEX的隐藏聚集索引。行是根据InnoDB分配给这样一个表中的行的ID来排序的。行ID是一个6字节的字段，随着新行插入而单调增加。因此，按行ID排序的行在物理上按插入顺序排列。

为什么不自己创建主键呢?此外，ORM不能识别这个隐藏的ID，这意味着您不能在代码中使用ID。

除了少数非常罕见的情况(可能是多对多关系表，或者临时用于批量加载大量数据的表)，我会使用以下说法:

如果它没有主键，它就不是表!

Marc

最好有一个主键。通过这种方式，它满足了第一种标准形式，并允许您继续沿着数据库规范化路径进行。

正如其他人所述，有一些理由不使用主键，但如果有主键，大多数情况下不会受到损害

在每个表上都有一个PK是一个很好的实践，但这不是必须的。大多数情况下，您需要一个唯一的索引，和/或聚集索引(这是PK与否)，这取决于您的需要。

查看联机图书的主键和聚集索引部分(适用于SQL Server)

"PRIMARY KEY约束标识具有唯一标识表中一行的值的列或列集。表中的任何两行都不能有相同的主键值。不能为主键中的任何列输入NULL。我们建议使用一个小的整数列作为主键。每个表都应该有一个主键。符合主键值条件的列或列的组合称为候选键。”

再看看这个:http://www.aisintl.com/case/primary_and_foreign_key.html

为了证明未来，你真的应该这么做。如果你想复制它，你需要一个。如果你想把它加入到另一张桌子上，你的生活(以及那些明年不得不维持它的可怜的傻瓜们的生活)将会轻松得多。