MySQL 将列定义为具有 AUTO_INCREMENT 的 UNIQUE 而不是作为主键

Question

我正在与一名契约(Contract)开发人员合作，他开始在没有定义主键的情况下创建表 (MySQL)。相反，他定义了一个带有 UNIQUE 约束和 AUTO_INCREMENT 的列。我以前从未见过这样做，所以我想了解以这种方式定义表的含义。 一个缺点是无法在需要时创建外键。以这种方式创建表还有其他一些影响，无论好坏。也许我在这里漏掉了一个概念……

Answer 1

在没有显式主键的情况下定义 MySQL 是一个非常非常糟糕的主意。
如果缺少 PK，MySQL 将创建一个隐式(但非常真实)整数自增主键。
此 PK 将包含在 InnoDB 中的每个辅助键中，并将确定您在 MyISAM 中的主要排序顺序。

后果
您刚刚降低了每次选择、插入和更新的性能。
没有任何目的。

InnoDB:获取表数据需要额外查找
在 InnoDB 中，需要进行额外的查找，因为所有二级索引都引用 PK 而不是行本身。

MyISAM:浪费空间
在 MyISAM 中，惩罚不是那么大，但您仍然拖着一个未使用的 4 字节未使用字段。

InnoDB + MyISAM:自增字段的无用生成
因为创建了一个隐式自动递增 PK，并且您还需要一个额外的自动递增键来进行连接；为了防止重复的自动增量字段，现在每个插入有 2 个而不是 1 个表锁。

InnoDB: with joins the lookup probem above mentioned
如果您使用不是 PK 的字段进行连接，则 InnoDB 需要每次连接 进行额外的查找以获取其他表的记录。

InnoDB:最糟糕的是你失去了覆盖索引的好处
你已经禁用了 InnoDB 中最好的优化之一，覆盖索引。
如果 MySQL 可以只使用索引中的数据解析查询，它就永远不会读取表，这将导致显着的速度提升。既然 InnoDB 中每个索引的 50% 是未使用的空间，您就失去了使用该优化的机会。

请用线索棒打败这个承包商!

链接:
http://www.xaprb.com/blog/2006/07/04/how-to-exploit-mysql-index-optimizations/ (链接慢，但推荐阅读)
O'Reilly on InnoDB's covering indexes http://tag1consulting.com/MySQL_Engines_MyISAM_vs_InnoDB

顺便说一句，如果你的承包商说，这并不重要，因为他正在使用 MyISAM，再打败他，你应该总是使用 InnoDB，除非你有充分的理由不用。
InnoDB 在生产中要安全得多，MyISAM 有它的用途，但太容易被破坏。