聚集索引和非聚集索引中使用的数据结构答案

【问题标题】：Data Structures used in Clustered and Non-Clustered Index聚集索引和非聚集索引中使用的数据结构
【发布时间】：2016-08-26 10:18:50
【问题描述】：

我阅读了聚簇索引和非聚簇索引并得出结论，我们对聚簇索引使用散列，对非聚簇索引使用 B+ 树（或 B 树）。我的结论对吗？如果不是，那么这两者在数据结构层面有什么区别？

【问题讨论】：

标签： sql database indexing relational-database database-indexes

【解决方案1】：

这个答案是在问题似乎集中在 MySQL 时写的。

既然您已经标记了问题 [mysql]，我们应该将讨论限制在那个 RDBMS 的可能性上。

这些天您最应该使用的“引擎”是 InnoDB。它主要有 B+Tree 索引。（它也有FULLTEXT 和SPATIAL，但我不会涉及它们。）它确实没有有“哈希”。

PRIMARY KEY 是一个聚集的 B+Tree。所有数据都按PK排序并存储到那个B+Tree中。 PK只能是集群的，只能是BTree。 PK 也是唯一的（在 MySQL 中）。

辅助键也是 B+树。它们包含二级索引的列。叶节点是主键的列。通过二级索引的“点查询”需要向下钻取二级 BTree，然后向下钻取主键。辅助键不能“聚集”。

对于一般用途，BTree 是最好的。哈希很少会更好。 Hash 对于范围扫描是没有用的，而 BTree，尤其是 B+Tree，非常适合这种情况。

当索引大于可以缓存在 RAM 中时，哈希是很糟糕的。通常，您要访问的“下一个”键与您触摸的最后一个键不相邻，因此很有可能需要 I/O。

【讨论】：

基本上这是一个面试问题，有人问我在聚簇和非聚簇索引中使用散列和 B 树在哪里。我应该怎么回答？
视情况而定。如果这个职位只针对 MySQL，那么这个问题就是无稽之谈，您最好的答案可能是（礼貌地）指出他们对 MySQL 的了解比您少。如果职位可能涉及其他引擎（MSSql、Oracle、Postgres 等），那么我没有给您他们正在寻找的答案——即您了解“聚集索引”、“哈希”与“BTree”的概念（也可能是“B+Tree”）、“primary”与“secondary”、“unique”等。在 Wikipedia 上查找这些内容。这些术语大部分是正交的。
感谢您的回复，但请您告诉解决方案适用于一般情况（包括 MSSql、Oracle、Postgres 等）
建议您更改标签以避免明显的 MySQL 焦点，然后希望其他人会加入。（我没有足够的广度或货币信息给您最新的十年回答。）

【解决方案2】：

简单来说，我们可以像下面这样解释。

聚集索引和非聚集索引都遵循 b-tree 结构，

for clustered index leaf node of the b-tree structure contains the Actual data.
for non clustered index leaf node of the b-tree structure points the address of the actual data.

【讨论】：

那么我们什么时候使用散列呢？
哈希会针对较大的字符串生成较短的固定长度键。如果您想了解有关哈希的更多信息，请通过以下链接阅读文章mobile.databasejournal.com/features/mssql/…
@UnnikrishnanR - 该链接讨论的是 MSSql，而不是 MySQL。