当我们创建聚集索引时，是否需要额外的空间？

Question

我问这个问题是为了恢复mysql数据库，我读到聚集索引是根据我们为创建聚集索引而提供的主键或列来排序的，在这些列中，键和记录指针有单独的空间。

另外，由于没有单独的索引表，所以聚集索引比非聚集索引更快，其中非聚集索引必须首先查看索引表，找到相应的记录指针并获取记录数据。

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

PS:我知道在这个问题上已经有一些类似的答案了，但我不明白。

Answer 1

没有占用额外的空间，因为每个InnoDB表都存储为聚集索引。实际上，只有聚集索引和二级索引。数据没有单独的存储，因为所有未编入索引的列都只是存储在聚集索引的终端节点中。您可能想在这里读到更多关于它的内容：https://dev.mysql.com/doc/refman/8.0/en/innodb-index-types.html

的确，如果使用辅助索引进行查找，然后在辅助索引中的列之外选择列，则InnoDB将执行某种双重查找。一次搜索辅助索引，这将导致找到要搜索的值的主键的值，然后使用这些主键搜索聚集索引以与其他列组合。

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

Answer 2

情况比你的问题复杂得多。

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

• 非叶BTree节点与数据“集群”PRIMARY KEY的开销约为1%。
• 如果您没有显式地指定一个PRIMARY KEY，它可能可以使用一个UNIQUE键作为PK。但如果没有，则将使用一个隐藏的6字节数字作为PK.这将占用更多的空间，如果你有，比方说，一个4字节的INT的PK！也就是说，没有PRIMARY KEY就不能创建表。
• 以上2项为TMI；将PK视为不占用额外空间。
• 是的，PK查找比使用辅助键查找快。但是如果你需要一个辅助键，那就创建它。玩第一次获取in，然后取行的游戏比在一个查询中完成所有工作要慢。
• 辅助键也使用BTree。但它是按键的列排序的，不包括所有其他列。相反，它包括PK的列。(因此，比尔提到了“双重查找”。)
• “覆盖索引”是包含特定SELECT所需的所有列的索引。在这种情况下，所有的工作都可以在索引的BTree中完成，从而避免了双重查找。也就是说，覆盖索引与主键查找一样快。(我猜想有20%的索引是“覆盖”的，或者可以通过添加一两列来覆盖。)
• BTrees有一堆开销。经验法则:将每列的大小相加( INT为4字节等)，然后乘以2或3。结果通常是对数据或索引Btree所需磁盘空间的一个很好的估计。
• 本讨论不涉及FULLEXT或SPATIAL索引。