Mysql 为什么InnoDB在创建表时需要聚集索引？

即使我没有主键或唯一键，InnoDB仍然会在合成列上创建一个集群索引，如下所述

那么，为什么InnoDB需要聚集索引呢？这里必须存在聚集索引，这有什么原因吗

在Oracle数据库或MSSQL中，我看不出他们需要这个。 而且，我认为集群索引与普通表相比也没有这么大的优势

的确，使用集群键查找数据不需要额外的磁盘读取，而且比没有集群索引时更快，使用物理rowID可以更快地查找辅助索引。 因此，我不认为有任何理由坚持使用它

其他供应商有“ROWNUM”之类的名称。InnoDB要简单得多。它只需要你通常想要的东西，而不是那种动物。在这两种情况下，它都是唯一标识行的值。这对于事务的本质是必需的——知道要锁定哪一行等，以提供事务完整性。（我在这里不谈理由。）

在要求（或提供）PK以及进行某些其他简化时，InnoDB牺牲了几个很少使用（或容易解决）的特性：多PK、多聚集索引、无PK等

由于“合成列”需要6个字节，因此即使不使用它，也最好只提供

id INT UNSIGNED NOT NULL AUTO_INCREMENT主键。但是如果您不使用它，但确实有一个非空的
UNIQUE
键，那么您也可以将其设置为PK。（默认情况下与MySQL相同。）

通过次键的查找首先从次键的BTree中获取PK值。然后向下钻取主BTree（数据由PK排序）以查找行。因此，次键的使用速度可能比PK慢。（通常这还不够慢。）因此，这指出了一个需要PK的设计决策。）（其他供应商使用ROWNUM或其他东西来定位记录，而不是PK。）

回到“为什么？”。MySQL中有许多决策，设计者说“对于这个免费产品来说，简单性更好，我们不必费心构建一些复杂但很少使用的功能。起初没有子查询（临时表是一种变通方法）。没有视图（它们只是语法糖）。没有物化视图（好的，这可能是失败的；但它们可以被模拟）。没有位映射、哈希或isam（etc）索引（BTree非常适合“全面”使用）

此外，通过始终使用数据“聚集”PK，通过PK进行的查找固有地比竞争对手更快（不通过ROWNUM）。（辅助键查找可能不会更快。）

另一个不同之处是MySQL在实现“索引合并”时非常晚，它使用两个索引，然后对结果进行ANDs或or。这对于ROWNUMs是有效的，但对于集群PKs则不然

（我不是MySQL/MariaDB/Percona的开发者，但我从1999年起就开始使用它们，并且几乎参加了所有MySQL的大型会议，在这些会议上，内部信息经常被泄露。因此，我认为我对他们的想法有足够的了解，可以给出这个答案。）
我不确定您希望我们说的话是否超出了您链接的文档中所描述的内容。Innodb创建者做出了一个设计决策。如果您不喜欢，请使用不同的表类型或rdbms产品。@Shadow我只想知道他们做出该决策的原因。我的目的是更多地了解聚集索引，而不是选择ect是一种可供使用的产品。当选择较少时，可能会做出大量优化决策。确定哪些关键点与开始的第一次对话相关“如果我们假设所有表都有聚集索引，我们可以。。。“不太可能。@PhanHoangMinh那么你应该问开发人员。我们只能猜测文档中的内容。非常感谢你的回答。因此，原因是使用群集主键比竞争对手（假设用户通常想要使用PK）能够更快地查找。还感谢你解释了“群集”的含义。”此外，我还发现了另一个原因：因为聚集索引可以存储到InnoDB内存中，并且数据可以逻辑检索，所以二级索引查找不需要额外的硬盘读取。考虑到发生数据碎片的情况，InnoDB中的二级索引查找并不比竞争对手慢。“集群”有很多含义。在我的回答中，我重点讨论了它对InnoDB PK的含义。（另一个含义涉及多台服务器协同工作。）“不需要额外的硬盘读取“--请记住，所有磁盘读取都可能被缓存。也就是说，可能存在也可能不存在这样的实际延迟。接触的磁盘块数（无论是在磁盘上还是缓存的）是一个重要指标。因此，应该注意哪些块可能被缓存。（等等--这本身就是一个很长的讨论。）