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

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

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。

我总是有一个主键，即使一开始我还没有想到它的目的。有几次，当我最终需要在一个没有PK的表中输入PK时，总是会遇到更多的麻烦。我认为总是有一个人会有更多的好处。

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

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

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

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

简而言之，没有。但是，您需要记住，某些客户机访问CRUD操作需要它。为了将来的校对，我总是倾向于使用主键。

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

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