SSD 将集群索引和非集群索引之间的性能差距缩小了多少？

Question

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

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

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

从Wikipedia page for SSDs 开始，SSD 的随机访问时间小于 0.1 毫秒，而机械硬盘的随机访问时间通常慢 10-100 倍。

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

Answer 1

只是总结建议（广泛用于简单评论）

考虑到一切都取决于非聚集索引和各个节点中的键分布（这完全是因果关系，只能以平均方式评估）仍然是任何访问都可以从性能中受益的事实SSD 磁盘。在这种情况下，介词的增加不是线性的，但仍然是可观的。因此，平均而言，它不应该是 1 到 100 的因数，确切地说是针对与分布随机性相关的问题，而是针对每一种表现出来的情况。访问速度快了 100 倍.. 在这种情况下，因果关系越多，效率就越高.. 情况发生了。 然而，在基础上有一个事实.. 磁盘上的每个操作都更加高效，因此通常非聚集索引的行为在最佳上下文中变得明确。

考虑到这一点，应该从根本上缩小差距，这应该归功于整个归档系统存在的上下文以及数据库的基础；从访问组成它的逻辑文件到实际保存数据的物理扇区

Answer 2

首先，额外的磁盘寻道并不是真正的“杀手”。在微秒和毫秒计数的高事务环境中，这可能是一个大问题。但是，对于运行时间较长的查询，它几乎没有什么区别。

如果数据库智能地“向前看”磁盘寻道，则尤其如此。数据库通常不等待数据，因为另一个线程正在预测需要哪些页面并努力将这些页面带回来。这通常通过在顺序扫描中获取“下一页”来完成。

SSD 将加速几乎所有操作。他们确实改变了优化参数。特别是，我认为它们的吞吐量相当快（尽管我没有专门跟上技术）。他们最大的胜利在于延迟——从发出磁盘块请求到检索到它的时间。

根据我的经验（几年前），对于大多数操作而言，使用 SSD 的性能与内存数据库相当。

这是否会使集群索引变得多余是另一回事。使用它们的一个关键地方是当您想要将相关的少量行（例如“未删除”）与大量行分开时。通过将它们放在相同的数据页中，聚集索引减少了正在读取的总行数——它不仅使读取速度更快。

Answer 3

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

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

The 2018 numbers:

• 磁盘寻道：3,000,000ns
• SSD 随机读取：16,000ns
• 主内存参考：100ns

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

---

你的评论：

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

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

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