不带主键的MySQL表（最佳实践）

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有PK的3种选择：

1. 显式PRIMARY KEY(...) -最佳做法：始终这样做。
2. 具有所有NON NULL列的第一个UNIQUE(...) 。 -比＃1笨拙。
3. 一个隐藏的6字节〜integer。 -由于它是隐藏的，因此很难在桌子上进行维护。

AUTO_INCREMENT与“自然” PK：

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

第二条规则：如果二级索引不止一个，则使用AI PK的空间可能会更少。 这是因为每个辅助密钥都包含PK的副本。

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

例子

• 多对多映射
• 优化wp_postmeta的索引

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

• “庞大的PK速度很慢” –也许，也许不是。
• “ VARCHAR PK速度很慢” –不会太大。

而且，如果您还有其他积蓄（例如，摆脱专栏），那可能会取代老太太的故事。

你的例子

up_id并提升user_name为PK。

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