SSD在多大程度上缩小了聚集索引和非聚集索引之间的性能差距?

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

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

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

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

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

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

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

The 2018 numbers :

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

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

回复您的评论:

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

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

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

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

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

考虑到这一点,应该从根本上缩小差距,这应该归功于整个归档系统存在的环境和数据库的基础;从访问组成它的逻辑文件到实际预处理数据的物理扇区。服务