MySQL中的聚集索引

聚集索引是单独创建和存储的，而不是MySQL中的实际数据吗？如果是这样，为什么不能有多个聚集索引。我们所需要做的就是创建另一个索引并将其存储在内存中

聚集索引至少部分是表的物理排序和存储方式，即磁盘上的行顺序。这就是为什么你只能有一个。但因为它反映了行的物理布局，所以它可能比典型的索引更紧凑、更高效

更新： 正如@RickJames在下面出色地指出的，在InnoDB（自5.5.5以来MySQL的默认引擎）中，查找通常是一个两阶段的过程。一个b-树将辅助密钥与主键相关联，第二个b-树将主键与数据记录的位置相关联。如果检索主键上的数据，则只需进行第二次查找。从这个意义上说，b树查找总是必要的

此外，根据MySQL文档：

通常，聚集索引与主键同义

它之所以被认为是“集群的”，而不仅仅是主键，是因为InnoDB试图根据主键对数据记录进行排序，并为将来的记录在其数据页中的正确位置留出空间

因此，不仅InnoDB主键上的查询比二级索引上的b-树查找要少一个，而且主键b-树也会因为磁盘上数据的物理顺序而大大减小

即使有一种机制可以生成直接指向数据记录的二级索引（如索引MyISAM），它的性能也不如InnoDB的主/聚集索引

---

因此，从根本上讲，是数据记录按主键进行（至少部分）物理排序，这会阻止您从二级索引获得相同的性能。

MySQL的InnoDB对其

主键执行以下操作：数据记录按PK顺序存储在一个B+树结构中。这允许快速点查询和范围扫描。也就是说，树“底部”的值包含表中的所有列

InnoDB的辅助键也在B+树中，但底部的值是PK列。因此，需要进行第二次查找以通过辅助键获取行

请注意，辅助键可以包含表中的所有列，从而起到第二个聚集索引的作用。缺点是对表的任何修改都必然涉及对两个btree的更改

相反，MyISAM将数据抛出到一个文件（即.MYD）中，并且在.MYI文件中，每个索引都位于自己的BTree中。每个BTree的底部是指向.MYD的指针（行号或字节偏移量）。PK的实现与辅助密钥没有任何不同

（注意：
FULLTEXT
和
SPATIAL
索引不在上述讨论范围内。）
AFAIK大多数数据库只允许一个聚集索引，因为该索引基于数据在某处的物理存储方式，通常只有该数据的一个副本。@TimBiegeleisen:谢谢您的澄清。因此，sql会在磁盘中创建数据的副本，并将其作为索引存储在内存中，在使用聚集索引的情况下也是如此。与sql在非聚集索引中所做的一样，它使用b-树创建索引，但叶节点仅包含指向实际数据的指针。下面的答案在我看来很好。@prem，由于记录是按聚集索引字段的顺序存储的，因此不需要b-树。在查找过程中反复将列表一分为二也有同样的效果，而且与b-树不同，它总是完全平衡的。@JoshuaRubin--不，b-树或类似的东西是必要的。