我问这个问题是用mysql数据库的repect。我读到聚集索引根据我们为制作聚簇索引而提供的主键或列对表进行排序，其中与非聚集索引一样，键和记录指针占用了单独的空间。
我也读到，因为没有单独的索引表，聚集索引比非聚集索引快，因为非聚集索引必须首先查看索引表找到相应的记录指针并获取记录数据
这是否意味着聚集索引没有占用额外的空间？
PS：我知道这个问题已经有一些类似的答案，但我无法理解。
没有占用额外的空间，因为每个InnoDB表都存储为聚集索引。实际上只有聚集索引和二级索引。没有单独的数据存储，因为所有未编制索引的列都只是存储在聚集索引的终端节点中。您可能想在此处阅读有关它的更多信息：https://dev.mysql.com/doc/refman/8.0/en/innodb-index-types.html
的确，如果您使用二级索引进行查找，然后选择二级索引中的列之外的列，InnoDB 将执行一种双重查找。一次搜索二级索引，这将生成找到要搜索的值的主键的值，然后它使用这些主键搜索聚集索引以与其他列合并。
自适应哈希部分缓解了这种双重查找，自适应哈希是经常搜索的值的缓存。运行查询时会自动填充此缓存。因此，随着时间的推移，如果您再次运行相同值的查询，则成本不会很高。
情况比你的问题复杂。
首先，我们只讨论ENGINE=InnoDB;其他引擎的工作方式不同。
-
非叶 BTree 节点使用数据"聚类"
PRIMARY KEY大约有 1% 的开销。 -
如果未显式指定
PRIMARY KEY，则可以使用UNIQUE键作为 PK。 但如果没有，那么 PK 将使用一个隐藏的 6 字节数字。 这将比您为 PK 使用 4 字节INT占用更多空间！ 也就是说，您无法创建没有PRIMARY KEY的表。 -
以上 2 项是 TMI;将 PK 视为不占用额外空间。
-
是的，PK 的查找比辅助键的查找更快。 但是，如果您需要辅助密钥，请创建它。 玩一个先获取 id，然后获取行的游戏比在单个查询中完成所有工作要慢。
-
辅助密钥也使用 BTree。 但它按键的列排序，不包括所有其他列。 相反，它包括 PK 的列。 (因此比尔提到的"双重查找"。
-
"覆盖索引"是包含特定
SELECT所需的所有列的索引。 在这种情况下，所有工作都可以在索引的 BTree 中完成，从而避免双重查找。 也就是说，覆盖索引与主键查找一样快。 (我猜 20% 的索引是"覆盖"的，或者可以通过添加一两列来覆盖。 -
B有一堆开销。 经验法则：将每列的大小相加(
INT等为 4 个字节)，然后乘以 2 或 3。 结果通常是对数据或索引树所需的磁盘空间的良好估计。 -
本讨论不涉及
FULLEXT或SPATIAL索引。