MySQL中的聚集索引

Question

聚簇索引是否与MySQL中的实际数据分开创建和存储，如果是，那么为什么我们不能有多个聚簇索引。 我们需要做的就是创建另一个索引并将其存储在内存中。

Answer 1

聚集索引至少部分是对表进行物理排序和存储的方式，即磁盘上的行顺序。 因此，您只能拥有一个。 但是，由于它反映了行的物理布局，因此它可能比典型索引更紧凑，性能更高。

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

此外，根据MySQL文档：

通常，聚簇索引与主键同义。 1

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

因此，在InnoDB主键上进行的查询不仅比二级索引少一个b树查找，而且由于磁盘上数据的物理排序，因此主键b树可以显着减小。

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

因此，从根本上讲，这是数据记录按主键的（至少部分）物理排序，这使您无法从辅助索引获得相同的性能。

Answer 2

MySQL的InnoDB对其PRIMARY KEY执行以下操作：数据记录按PK顺序存储在B + Tree结构中。 这样可以进行快速的点查询和范围扫描。 也就是说，树的“底部”的值具有表的所有列。

InnoDB的辅助键也位于B + Tree中，但最下面的值是PK列。 因此，需要第二次查找以通过辅助键来获取一行。

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

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

（注意：以上讨论未涵盖FULLTEXT和SPATIAL索引。）