简单的回答是:是的。

长一点的回答:

你需要你的桌子可以连接到一些东西上 如果您希望您的表被集群，您需要某种类型的主键。 如果您的表设计不需要主键，请重新考虑您的设计:很可能您遗漏了一些东西。为什么要保留相同的记录?

在MySQL中，如果你没有显式地指定主键，InnoDB存储引擎总是会创建一个主键，从而产生一个你无法访问的额外列。

注意，主键可以是复合键。

如果您有一个多对多链接表，您可以在链接中涉及的所有字段上创建主键。因此，您可以确保没有两条或更多的记录描述一个链接。

除了逻辑一致性问题之外，大多数RDBMS引擎都将受益于将这些字段包含在唯一的索引中。

由于任何主键都涉及创建唯一的索引，因此应该声明它并获得逻辑一致性和性能。

请参阅我博客中的这篇文章，了解为什么应该总是在唯一的数据上创建唯一的索引:

使索引唯一

附注:在一些非常非常特殊的情况下，您不需要主键。

大多数情况下，它们包含的日志表由于性能原因没有任何索引。

几乎每次我创建一个没有主键的表时，我都认为我不需要主键，最终我会返回并添加一个主键。现在，我甚至用一个自动生成的标识字段作为主键来创建连接表。

我知道为了在。net中使用gridview的某些特性，你需要一个主键，以便gridview知道哪一行需要更新/删除。一般的做法应该是有一个主键或主键集群。我个人更倾向于前者。

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

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

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。

我的职责是维护海外开发团队创建的应用程序。现在我在应用程序中有各种各样的问题，因为原始的数据库模式不包含一些表上的主键。所以请不要让别人因为你糟糕的设计而受苦。在表上设置主键总是一个好主意。