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

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

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

从SSD的维基百科页面，SSD的随机访问时间小于0.1 ms，而机械硬盘的随机访问时间通常慢10-100倍。

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

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

SSD有助于加快基于IO的操作，特别是涉及磁盘查找的操作。它比旋转的磁盘快得多。但是RAM仍然比最好的固态硬盘快几个数量级。

2018年数字：

• 磁盘搜索：3000000ns
• SSD随机读取：16000ns
• 主存储器参考：100ns

RAM仍然以巨大的优势胜过耐用存储。如果您的数据集(或者至少是数据集的活动子集)适合RAM，则无需担心磁盘存储和SSD存储之间的区别。

回复您的评论：

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

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

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

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

如果数据库智能地执行"向前看"磁盘查找，则情况尤其如此。数据库通常不等待数据，因为另一个线程正在预测需要什么页面，并正在努力将这些页面恢复。这通常是通过连续扫描"下一页"来完成的。

固态硬盘将大大加快所有操作的速度。它们确实改变了优化参数。特别是，我认为它们在吞吐量方面速度相当快(尽管我没有特别跟上技术的发展)。他们最大的成功在于延迟——发出磁盘块请求的时间和获取请求的时间。

根据我的经验(几年前)，对于大多数操作来说，使用SSD的性能相当于内存中的数据库。

这是否会使集群索引冗余是另一回事。使用它们的一个关键位置是，当您想将相关的少量行(称为"未删除")与较大的行分开时。通过将它们放在相同的数据页中，聚集索引减少了被读取的行的总数——它不仅仅使读取速度更快。

只是简单的建议(为了简单的评论)

考虑到一切都取决于未聚集索引和各个节点中密钥的分布(这完全是因果关系，只能用平均值来评估)，仍然存在这样一个事实：任何访问都会从SSD磁盘的性能中获益。在这种情况下，介词的增加不是线性的，而是实质性的。因此，平均而言，它不应该是1到100的系数，这正是与分布的随机性有关的问题，而应该是在每种情况下，这一点都会显现出来。访问速度快100倍。在这种情况下，效率越高，因果关系就越强。情况发生了。然而，在基地有一个事实……磁盘上的每个操作都更加高效，因此一般来说，未聚集索引的行为在最佳上下文中是显式的。

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