我做了一些研究，但找不到明确的答案。
我有一个简单的多对多关系表，user_id将是外来的，group_id将是外来的，是否有理由添加PRIMARY KEY？
答案 0 :(得分：2)
我将从接受的答案中发表不同意见。您应该不添加自动增量主键以加入（或交叉引用）表。这就是原因。
首先，你不会使用它。此表存在的唯一原因是跟踪用户和组之间的多对多关系。添加自动增量字段只会添加另一个您不会阅读的字段。换句话说，您要查询此表的唯一时间是因为您想要查看哪些用户属于某个组，或者哪个用户组是其成员。在这两种情况下，都不会使用这个额外的主键表。
其次，如果您向此表添加其他数据，主键仍然无用。考虑一下：如果我们添加一个字段来表明某个组成员身份对于给定用户来说是“主要”，我们仍然需要知道用户和组以使这个“主要”有意义。
技术上你从不需要任何表的自动递增的“代理”键。您只需要一个您知道唯一的字段或字段集（从而使我们至少处于第二范式）。问题在于，大多数情况下，我们非常难以预测什么是足够独特的，所以我们添加这个额外的密钥来保护自己免受这个问题。 交叉引用不是我们预测不好的情况之一。用户将永远不会是同一组的成员两次，并且永远不会是这样的情况一个组将包含相同的用户两次。我们知道该组合是唯一的，因此额外的代理键不会增加任何内容。
但是，请注意，如果您要向这样的表添加字段（除了两个外键），您实际上可能正在建模一些并非真正多对多的东西。实际上，您可能正在建模一对多。例如，如果您要将字段添加到用户到组的映射，您实际上可能正在建模“成员资格”实体。 那可能已经获得了代理键，因为在不同的时间让一个用户拥有不同成员资格的同一组可能会有意义。但同样，这是建立别的东西而不是多对多的关系。
答案 1 :(得分：1)
如果您想要对该表做一些更有趣的事情（让我们称之为表A），例如将卫星从A中删除或者使用另一个连接A的多对多表，该怎么办？和其他一些表B？
可能有一段时间您希望表格引用特定user_id的某个group_id出现？
基本上，如果您想要引用表A，或者表A是其他表的父项，则表A上需要一个主键。在我看来，在关系中DB，很可能你想在某个时候引用它。
所以我说添加一个自动增量PK（假设您可以使用重复的user_id, group_id行，例如@Leslie在评论中说。
另外，请注意，如果你给它一个自动增量PK，那么仍然值得将user_id上的索引和group_id上的索引用于加入
其他类似的SO问题：