大多数SQL关系数据库都支持表中聚集索引的概念。聚集索引（通常实现为B树）表示给定表中的实际记录，并由该索引在磁盘/存储上的物理顺序进行排序。这种特殊的聚集索引的一个优点是，在遍历B树以搜索一条记录或一组记录后，可以在叶节点上立即找到实际数据。
这与 non 聚集索引形成对比。非聚集索引存在于聚集索引之外，并且还使用一个或多个列对基础数据进行排序。但是，叶节点可能没有查询中所需的所有列的数据。在这种情况下，数据库必须对原始数据进行磁盘搜索以获取此信息。
在我在堆栈溢出和其他地方看到的大多数数据库资源中，这种额外的磁盘查找被视为对性能的重大损失。我的问题是，假设所有数据库文件都存储在固态驱动器（SSD）上，该分析将如何改变？
从Wikipedia page for SSDs开始，SSD的随机访问时间小于0.1毫秒，而机械硬盘的随机访问时间通常要慢10-100倍。
SSD是否会缩小聚簇索引和非聚簇索引之间的距离，从而使前者对整体性能的重要性降低？
答案 0 :(得分：1)
首先，额外的磁盘搜寻并不是真正的“杀手“”。在微秒和毫秒计数的高事务环境中，这可能是个大问题。但是，对于运行时间较长的查询，它的作用不大。
如果数据库能够智能地“向前看”磁盘搜索，则尤其如此。数据库通常不在等待数据，因为另一个线程正在预测将需要哪些页面并致力于将其恢复。通常，只需在顺序扫描中获取“下一页”即可。
SSD几乎可以加快所有操作的速度。它们确实更改了优化参数。特别是，我认为它们的吞吐速度相当快（尽管我没有特别跟上该技术）。他们的最大胜利在于延迟-从发出对磁盘块的请求开始到获取磁盘块的时间。
根据我的经验（已有几年的历史），对于大多数操作，使用SSD的性能可与内存数据库相媲美。
这是否会使群集索引变得多余是另一回事。使用它们的一个关键地方是当您要将大量的相关行（例如“未删除”）分开时。通过将它们放在相同的数据页中，聚簇索引减少了读取的总行数，这不仅使读取速度更快。
答案 1 :(得分：1)
首先，聚集索引不能保证以物理方式按索引顺序存储行。例如，InnoDB可以以非顺序方式存储聚簇索引。即，包含表的连续行的两个数据库页面可能在物理上彼此靠近，或者在表空间中以任意顺序存储。聚集索引的B树数据结构具有指向叶页的指针，但不必以任何顺序存储它们。
SSD有助于加快基于IO的操作，尤其是涉及磁盘查找的操作。它比旋转的磁盘快得多。但是RAM仍然比最好的SSD快几个数量级。
RAM仍远胜于持久存储。如果您的数据集（或至少是数据集的活动子集）适合RAM，则无需担心磁盘存储和SSD存储之间的差异。
发表评论：
聚集索引非常有用，因为当主键查找搜索B树并找到叶节点时，该行的所有其他字段都与此主键值相关联。
与MyISAM相比，后者的主键索引与表的行分开。查询搜索主键索引的B树，并在叶节点处找到一个指向数据文件中对应行存储位置的指针。因此，它必须再次搜索数据文件。
这不一定意味着InnoDB中的聚集索引是连续存储的。可能需要略过一点才能读取表空间的所有页面。这就是为什么将页面放在缓冲池的RAM中如此有帮助的原因。
答案 2 :(得分：0)
仅提出建议（对于简单的评论，大致来说就是这样）
考虑到一切都取决于非聚集索引和各个节点中键的分布（这完全是因果关系，只能用平均值来评估）仍然是这样的事实，即任何访问都会受益于性能SSD磁盘。在这种情况下，介词的增加不是线性的，而是相当大的。因此，对于与分布的随机性有关的问题，平均而言，它不应是1到100的因数，而对于表现这种情况的每种情况，它均不应为1到100。访问速度提高了100倍..在这种情况下，情况越有因果关系，效率就越高。 但是，实际上存在一个事实。.磁盘上的每个操作都效率更高，因此，通常，在最佳情况下，非聚集索引的行为会变得很明显。
考虑到这一点，应从根本上缩小差距，并且由于整个文件系统的存在以及数据库的基础，这种差距应该发生；从访问组成它的逻辑文件到实际保存数据的物理扇区中