sql - SSD 将聚簇索引和非聚簇索引之间的性能差距缩小了多少？

Question

大多数 SQL 关系数据库都支持表中聚集索引的概念。聚簇索引通常作为 B 树实现，表示给定表中的实际记录，按磁盘/存储上的索引物理排序。这种特殊的聚簇索引的一个优点是，在遍历 B 树搜索一条记录或一组记录后，可以立即在叶节点处找到实际数据。

这与非 聚集索引形成对比。非聚集索引存在于聚集索引之外，也使用一个或多个列对基础数据进行排序。但是，叶节点可能没有查询所需的所有列的数据。在这种情况下，数据库必须对原始数据进行磁盘搜索以获取此信息。

在我在 Stack Overflow 和其他地方看到的大多数数据库资源中，这种额外的磁盘查找被视为严重的性能损失。我的问题是，假设所有数据库文件都存储在固态驱动器 (SSD) 上，此分析将如何改变？

来自Wikipedia page for SSDs ，SSD 的随机存取时间小于 0.1 毫秒，而机械硬盘的随机存取时间通常要慢 10-100 倍。

SSD 是否缩小了聚集索引和非聚集索引之间的差距，从而使前者对整体性能变得不那么重要？

Answer 1

首先，聚簇索引不保证行在物理上按索引顺序存储。例如，InnoDB 可以以非顺序方式存储聚簇索引。也就是说，包含表的连续行的两个数据库页面可能在物理上彼此靠近存储，或者在表空间中相距很远，并且以任一顺序存储。聚集索引的 B 树数据结构具有指向叶页的指针，但它们不必以任何顺序存储。

SSD 有助于加快基于 IO 的操作，尤其是涉及磁盘寻道的操作。它比旋转的磁盘快得多。但 RAM 仍然比最好的 SSD 快几个数量级。

The 2018 numbers :

• 磁盘寻道:3,000,000ns
• SSD 随机读取:16,000ns
• 主内存引用:100ns

RAM 仍然远远胜过持久存储。如果您的数据集(或至少数据集的事件子集)适合 RAM，则您无需担心磁盘存储和 SSD 存储之间的差异。

---

回复你的评论:

聚簇索引很有帮助，因为当主键查找在 B 树中搜索并找到叶节点时，就在该行的所有其他字段与该主键值相关联。

与 MyISAM 相比，MyISAM 的主键索引与表的行分开。查询搜索主键索引的 B 树，并在叶节点处找到指向数据文件中存储相应行的位置的指针。因此它必须对数据文件进行第二次查找。

这并不一定意味着InnoDB中的聚簇索引是连续存储的。它可能需要跳过一点才能读取表空间的所有页面。这就是将 RAM 中的页面放在缓冲池中如此有用的原因。