当我们创建一个聚集索引时，它会占用额外的空间吗？

Question

我问的是关于 mysql 数据库的这个问题。我读到聚集索引根据我们提供的用于制作聚集索引的主键或列对表进行排序，而在非聚集索引中，键和记录指针占用了单独的空间。

另外我读到没有单独的索引表，聚集索引比非聚集索引更快，因为非聚集索引必须首先查看索引表找到相应的记录指针并获取记录数据

这是否意味着聚集索引没有额外的空间？

PS：我知道这个问题已经有一些类似的答案，但我无法理解。

Answer 1

没有占用额外空间，因为每个 InnoDB 表都存储为聚集索引。 实际上只有聚集索引和二级索引。 没有单独的数据存储，因为所有未索引的列都简单地存储在聚集索引的终端节点中。 您可能想在此处阅读更多信息：https://dev.mysql.com/doc/refman/8.0/en/innodb-index-types.ZFC35FDC70D5FC69D269E3Z883A822C75A

确实，如果您使用二级索引进行查找，然后使用二级索引中的 select 列，InnoDB 将执行一种双重查找。 一次搜索二级索引，这会导致找到您正在搜索的值的主键的值，然后它使用这些主键来搜索聚集索引以与其他列组合。

自适应 Hash部分缓解了这种双重查找，它是频繁搜索值的缓存。 此缓存会在您运行查询时自动填充。 因此，随着时间的推移，如果您再次对相同的值运行查询，成本不会那么高。

Answer 2

情况比你的问题复杂。

首先，我们只讨论ENGINE=InnoDB ； 其他引擎的工作方式不同。

• 非叶 BTree 节点将PRIMARY KEY与数据“集群”大约有 1% 的开销。

• 如果您没有明确指定PRIMARY KEY ，它可能能够使用UNIQUE键作为 PK。 但如果不是，那么 PK 将使用一个隐藏的 6 字节数字。 这将比如果你有一个 4 字节的INT用于 PK 的空间更多，也就是说，你不能创建没有PRIMARY KEY的表。

• 以上2项为TMI； 认为 PK 不占用额外空间。

• 是的，通过 PK 查找比通过辅助键查找更快。 但是，如果您需要辅助密钥，请创建它。 玩先获取 id，然后获取行的游戏比在单个查询中完成所有工作要慢。

• 辅助键也使用 BTree。 但它按键的列排序，不包括所有其他列。 相反，它包括 PK 的列。 （因此比尔提到的“双重查找”。）

• “覆盖索引”是包含特定SELECT所需的所有列的索引。 在这种情况下，所有工作都可以在索引的 BTree 中完成，从而避免双重查找。 也就是说，覆盖索引与主键查找一样快。 （我猜想 20% 的索引是“覆盖”的，或者可以通过添加一两列来覆盖。）

• BTrees 有很多开销。 经验法则：将每列的大小相加（ INT等 4 个字节），然后乘以 2 或 3。结果通常可以很好地估计 Data 或 Index Btree 所需的磁盘空间。

• 本讨论不包括FULLEXT或SPATIAL索引。