Question

我有一个表users，其中包含多个用户信息。我想将用户特定权限存储在另一个表中。

我是否需要在user_permissinos表中使用主键 up_id ，即使它不会在任何地方使用？我知道总是建议在表中使用主键，但在这种情况下，对我来说没有任何意义。如果我需要加入两个表，我将在user_id上加入up_of_user。

Table `user`
==========================
user_id int(11) PK AI NN
user_name varchar(50)
...


Table `user_permissions`
=======================================
up_id int(11) PK AI NN
up_of_user int(11) FK of user.user_id
up_edit_post tinyint(4) DEFAULT '0'

Answer 1

请阅读MySQL的文档：

表的主键表示您在最重要的查询中使用的列或列集。它具有关联的索引，以实现快速查询性能。查询性能受益于NOT NULL优化，因为它不能包含任何NULL值。使用InnoDB存储引擎，表格数据在物理上可以根据主键或列进行超快速查找和排序。

如果您的表很大且很重要，但没有明显的列或列集用作主键，则可以创建一个单独的列，其中包含自动增量值以用作主键。当您使用外键连接表时，这些唯一ID可以作为指向其他表中相应行的指针。

根据我的经验和知识，如果您没有定义主键，数据库将创建一个隐藏的主键。在你的情况下，我应该保留主键。

感谢@AaronDigulla的解释......：

必要吗？没有在幕后使用？好吧，它被保存到磁盘并保存在行缓存等中。删除会稍微提高你的性能（使用精确到毫秒精度的手表）。

但是...下次有人需要创建对此表的引用时，他们会诅咒你。如果他们勇敢，他们将添加PK（并等待DB创建列的时间很长）。如果他们不勇敢或愚蠢，他们将开始使用业务密钥（即数据列）创建引用，这将导致维护噩梦。

结论：由于拥有PK的成本（即使它没有使用ATM）是如此之小，所以就这样吧。

Answer 2

InnoDB有3种PK选择：按顺序，

明确PRIMARY KEY(...) - 最佳做法：始终这样做。
包含所有UNIQUE(...)列的第一个NON NULL。 - 比＃1更粗略。
一个隐藏的6字节〜整数。 - 由于它是隐藏的，因此难以对桌面进行维护。

AUTO_INCREMENT与“自然”PK：

第一条规则：如果您有自然键，请使用它而不是添加人工ID。我创建的大约2/3的表具有“自然”PK，有时是“复合”（多列）。

第二条规则：如果您有多个辅助索引，则使用AI PK可能需要更少的空间。这是因为每个辅助密钥都包含PK的副本。

第三条规则：对于只有一个二级索引，这是一个折腾。

<强>实施例

老太太的故事又名“假新闻”

“笨重的PK很慢” - 也许，也许不是。
“VARCHAR PK很慢” - 不是很多。

如果你有其他节省（例如，摆脱一个专栏），这可能会超越旧妻子的故事。

您的示例

抛出up_id并宣传user_name成为PK。

听起来user和user_permissions的关系是1：1？有两个具有相同PK的表是非常罕见的。通常情况下，这两个表应合并为一个。

没有主键的MySQL表（最佳实践）

2 个答案: