MySQL中的聚集索引答案

【问题标题】：Clustered Index in MySQLMySQL中的聚集索引
【发布时间】：2018-05-22 15:30:28
【问题描述】：

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

【问题讨论】：

AFAIK 大多数数据库只允许单个聚集索引，因为索引是基于数据在某处物理存储的方式，并且通常存在该数据的单个副本。
@TimBiegeleisen：感谢您的澄清。那么，sql 是否会在磁盘中创建数据副本并将其作为索引存储在内存中以及聚集索引的情况下。就像 sql 在非聚集索引的情况下所做的那样，它使用 b-tree 创建一个索引，但叶节点只包含指向实际数据的指针
下面的答案对我来说看起来不错。
@prem，因为记录是按照集群索引字段的顺序存储的，所以不需要 b-tree。在查找过程中反复将列表分成两半具有相同的效果 - 与 b 树不同，它始终是完美平衡的。
@JoshuaRubin -- 不。BTree 或类似的东西，是必要的。

标签： mysql database indexing clustered-index

【解决方案1】：

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

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

另外，根据 MySQL 文档：

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

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

正因为如此，不仅对 InnoDB 主键的查询比二级索引少一次 b-tree 查找，而且由于磁盘上数据的物理排序，主键 b-tree 可以明显更小。

按理说，即使有一种机制可以创建直接指向数据记录的二级索引（如索引 MyISAM），它的性能也不会像 InnoDB 的主/聚集索引那样好。

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

【讨论】：

【解决方案2】：

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

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

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

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

（注意：FULLTEXT 和 SPATIAL 索引不在上述讨论范围内。）

【讨论】：