MySQL使用AUTO_INCREMENT而不是主键将列定义为UNIQUE

Question

我正在与合同开发人员合作,他们开始创建表(MySQL)而没有定义主键.相反,他正在使用带有AUTO_INCREMENT的UNIQUE约束来定义列.我以前从未见过这样做过,所以我想了解以这种方式定义表的含义.一个缺点是如果需要就无法创建外键. 以这种方式创建表格有什么其他影响,无论好坏.也许我在这里错过了一个概念......

Answer 1

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

后果
您刚刚放慢了每个选择,插入和更新的性能.
没有任何目的.

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

MyISAM:浪费的空间
在MyISAM中,惩罚并不是那么好,但是你还在拖动一个未使用的4字节未使用字段.

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

InnoDB:加入上面提到的查找探测器加倍
如果使用不是PK的字段进行连接,InnoDB需要对每个连接进行额外查找以获取该另一个表的记录.

InnoDB:最糟糕的是你失去了覆盖索引的好处
你已经禁用了InnoDB中最好的优化之一,涵盖了索引.
如果MySQL只使用索引中的数据来解析查询,它将永远不会读取表,这将导致显着的速度增益.既然InnoDB中每个索引的50%都是未使用的空间,那么您只是没有使用该优化的机会.

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

链接:
http://www.xaprb.com/blog/2006/07/04/how-to-exploit-mysql-index-optimizations/ (慢速链接,但建议阅读).
O'Reilly关于InnoDB的覆盖索引 http://tag1consulting.com/MySQL_Engines_MyISAM_vs_InnoDB

顺便说一句,如果你的承包商说,这并不重要,因为他正在使用MyISAM,再次击败他,除非你有充分的理由,否则你应该总是使用InnoDB.
InnoDB在生产方面更安全,MyISAM有其用途,但太容易被破坏.