每个MySQL表都应该有一个自动递增的主键吗?

JM4*_*JM4 5 sql database database-design normalization

  • 我理解主键的价值.
  • 我理解索引的价值.

每个 MySQL表都应该有一个自动递增的主键(理想情况下是INT字段类型)吗?

更新

@Raj More的答案看起来效率最高.但是,当我考虑它时,问题是这个自动递增的主键ID将如何与其他表相关联.例如:

表格1

ID  |   firstname  |   lastname | email
----------------------------------------
1   |    john      |   doe      | 1@email.com
2   |    sarah     |   stow     | 2@email.com
3   |    mike      |   bro      | 3@email.com
Run Code Online (Sandbox Code Playgroud)

表2

ID  | memberid |    display      |    address
--------------------------------------------
1   |    1     | funtime zone    |   123 street
2   |    3     | silly place llc |  944 villa dr 
Run Code Online (Sandbox Code Playgroud)

在上面的示例中,消费者可以访问该站点并选择注册免费产品/服务.如果消费者选择,他们可以提供额外的信息(存储在表2中)以进行额外的邮寄等.我看到的问题是这些表如何与"主键自动增量字段"相关.在表2中,'memberid'与表1的ID有关,但这并非"非常"清楚.放入表2的任何新信息将增加1,而并非所有消费者都会选择参与表2所需的数据.

ype*_*eᵀᴹ 6

我不是代理键的忠实粉丝.我还没有看到一个场景,我更愿意为数据库的每个表使用一个.

我会说没有.

阅读这个答案:surrogate-vs-natural-business-keys


以上可能被视为讽刺或火焰(尽管令人惊讶的许多赞成票),所以它被删除了.

在一般情况下,代理和自然键上有很多问题和答案,所以我觉得这个问题更像是重复.我的观点是代理键很好并且非常有用,主要是因为自然键可以在连接表链的低端导致非常大的主键 - 许多RDBMS处理不好,聚簇索引变大,等等但是说" 每个 MySQL表都应该有一个自动递增的主键 "是一个非常绝对的陈述,我认为有些情况下它们真的提供很少或根本没有.

由于OP更新了问题,我将尝试评论该特定主题.

我认为这恰好是自动增量主键不仅无用而且增加负值的情况.假设table1table21:1关系中,memberid既可以是Primary Key和一Foreign Keytable1.

添加一个autoincrementing id列会添加一个索引,如果它是一个聚簇索引(如InnoDB PK索引),则会增加索引的大小memberid.更重要的是,如果你有这样一个自动递增的id,那么table2到其他表的一些JOIN将必须使用它id(与1:ntable2相关的表memberid的JOIN )和一些使用(与表1:n相关的JOIN table1).如果你只有memberid这两种类型的JOIN都可以使用memberid.