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

问题描述

| 我正在与一个合同开发人员合作，该合同开发人员开始创建表（MySQL）而不定义主键。相反，他正在定义具有UNIQUE约束且具有AUTO_INCREMENT的列。我以前从未见过这样做，所以我想了解以这种方式定义表的含义。如果需要，不利的一面是无法创建外键。用这种方式创建表还有其他的好处或坏处。也许我在这里想念一个概念……     

解决方法

        在没有显式主键的情况下定义MySQL是一个非常非常糟糕的主意。 如果缺少PK，MySQL将创建一个隐式（但非常真实）的整数自动递增主键。 此PK将包含在InnoDB的每个辅助键中，并将确定MyISAM中的主要排序顺序。 后果 您刚刚降低了每次选择，插入和更新的性能。 毫无目的。 InnoDB：获取表数据需要额外的查找 在InnoDB中，需要进行额外的查找，因为所有二级索引都引用PK而不是行本身。 MyISAM：浪费空间 在MyISAM中，惩罚不是那么大，但是您仍在拖延4个未使用的未使用字段。 InnoDB + MyISAM：自动生成字段的无用生成 因为创建了隐式自动增量PK，并且您还需要一个额外的自动增量键才能进行连接；为了防止重复的自动增量字段，现在每个插入没有1个表锁。 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有其用途，但很容易损坏。     ,        这不会阻止外键，但是会影响使用该字段的查询的性能。每当您必须查询表并指定一些条件以根据列的值过滤记录时（例如WHERE子句），都应使用索引。     ,        主键只是结合了NOT NULL约束的唯一索引，如果您满足这些要求而没有PK，那么就性能而言就不会造成任何损害，当然，它仍然没有多大意义，因为这会造成混乱。