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