在使用固态硬盘（SSD）时，聚簇索引的概念在数据库设计中是否合理呢？

Question

在使用固态硬盘（SSD）时，聚簇索引的概念在数据库设计中是否合理呢？

44

在设计SQL服务器数据架构以及后续的查询、存储过程、视图等时，对于专门部署在SSD平台上的数据库设计来说，考虑聚集索引和磁盘上的数据顺序是否有意义呢？根据http://msdn.microsoft.com/en-us/library/aa933131(v=sql.80).aspx的解释，"聚集索引决定了表中数据的物理顺序"。在物理磁盘平台上，我认为考虑它们的设计是有意义的，因为通过对数据进行物理扫描来检索"连续"行可能比遍历整个表更高效。而在SSD平台上，所有数据读取都使用相同的寻址方式。没有"物理顺序"的概念，数据读取不是以位元存储在同一块硅片上的"连续"方式。所以，在设计应用程序数据库的过程中，聚集索引的考虑对于这个平台是否相关呢？我的初步想法是它不相关，因为"有序数据"的概念并不适用于SSD存储和寻址/检索优化。

编辑：我知道SQL Server会创建一个，我只是在思考在设计/优化过程中是否考虑这个问题是否有意义。

- Matthew PK

1这个普遍领域的一些论文（与你的问题无关）包括《查询优化器是否需要支持SSD？》和《固态硬盘的查询处理技术》。 - Martin Smith

3个回答

23

如果您使用一个选择得当的聚集索引，您很有可能在较少的数据页中获取到所需的所有相关数据。也就是说，您可以用更少的内存来保存所需的数据。无论您使用旋转硬盘还是固态硬盘，这都会带来好处。但是您说得对，聚集索引的另一个好处——按顺序读写相关数据而不是进行多次磁盘寻道——对于固态硬盘来说并不是一个重要的好处，因为相比旋转硬盘，寻道操作对固态硬盘的性能影响不大。

回复@Matthew PK的评论。

当然，RAM中的位置A和RAM中的位置B一样快。这不是重点。我说的是当你需要的所有数据如果分散在许多页面中，而无法全部放入RAM时的情况。任何给定的页面可能只包含你感兴趣的少量数据。因此，关系型数据库管理系统必须在访问A、B和其他行时不断加载和清除页面。这就是性能损失的原因。

最好的情况是每个页面都充满你感兴趣的数据，希望所有后续的行请求都从RAM中的页面提供服务。使用聚集索引是确保数据被组合到较少页面上的好方法。

- Bill Karwin

13

是的，它绝对仍然有意义。您在处理中考虑得太低级了。SQL Server（在非常简化的解释中）使用B树架构存储聚集数据。这允许基于聚集索引键值快速检索数据。

堆（没有聚集索引）没有数据的顺序。在这里最重要的事情是，在堆中数据页没有链接在链接列表中。

因此，答案是肯定的，即使在SSD上，仍然有意义在表上创建聚集索引。这完全取决于SQL Server必须筛选多少数据才能获得结果数据。通过聚集索引查找，可以将其最小化。

参考：http://msdn.microsoft.com/en-us/library/ms189051.aspx

- Shark

将会有一个聚集索引。关键是在SSD平台上，是否对其进行查找很重要。 - Matthew

5是的，搜索很重要。无论使用什么媒介，3次阅读相对于300次阅读来说都更快。 - Thomas Stringer

- Remus Rusanu · Accepted Answer

问问自己另一个问题：如果整个数据库都在内存中，我永远不需要访问磁盘，是要将数据存储在有序的B树中还是无序的堆中？

这个问题的答案取决于你的访问模式。在大多数情况下，你的访问需要单行查找（即寻址）和范围扫描。这些访问模式需要使用B树，否则效率低下。其他一些访问模式，在DW和OLAP中很常见，总是对整个表进行聚合，并且不会从范围扫描中获益。随着进一步的深入，会出现其他要求，比如将数据插入堆和B树中的速度可能对于大型ETL传输作业起到作用。但大多数情况下，答案归结为一个问题：你是在寻址还是范围扫描？绝大多数情况下，答案是肯定的。因此，设计通常需要一个聚集索引。

换句话说：仅仅因为以随机顺序从磁盘读取它很便宜，并不意味着你可以在64GB RAM扫描中破坏你的TLB和L2缓存行...