使用SSD时，数据库设计中的聚集索引概念是否明智？

在设计SQL Server数据架构和后续查询，存储过程，视图等时，对于明确要部署在SSD平台上的数据库设计，聚集索引的概念和磁盘上数据的顺序是否有意义？

“ http://msdn.microsoft.com/zh-cn/library/aa933131(v=sql.80).aspx
“聚集索引确定表中数据的物理顺序。”

在物理磁盘平台上，考虑到它们的设计对我来说很有意义，因为对数据进行物理扫描以检索“顺序”行比在表中查找更有效。
在SSD平台上，所有数据读取访问都使用相同的查找。就位存储在同一块硅片而言，没有“物理顺序”的概念，并且数据读取不是“顺序的”。

那么，在设计应用程序数据库的过程中，聚集索引的考虑是否与此平台相关？

我最初的想法不是因为“有序数据”的概念不适用于SSD的存储和查找/恢复优化。

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

问自己另一个问题：如果整个数据库都在内存中，而我又不必触摸磁盘，我是否要将数据存储在有序的B树中，还是要将数据存储在无序的堆中？

该问题的答案将取决于您的访问方式。在大多数情况下，您的访问需要单行查找（即搜索）和范围扫描。这些访问模式需要B树，否则效率低下。DW和OLAP中常见的其他一些访问模式始终总是端对端地对整个表进行聚合，并且它们不会从范围扫描中受益。随着钻探的进一步深入，其他需求也逐渐浮出水面，例如，插入和分配到堆与B-Tree的速度可能对庞大的ETL传输作业起作用。但是大多数时候，答案实际上都归结为一个问题：您是寻找还是进行范围扫描？绝大多数的答案是“是”。因此，绝大多数设计需要聚集索引。

换句话说：仅仅因为以随机顺序从磁盘读取它便宜，并不意味着您可以将您的TLB和L2行丢弃在64Gb RAM扫描中。

如果使用精心选择的聚集索引，则更有可能在较少的数据页中获得所需的所有相关数据。也就是说，您可以在更少的内存中保存所需的数据。无论使用旋转磁盘还是SSD，这都将带来好处。

但是您是正确的，聚集索引的另一个好处-顺序读取/写入相关数据，而不是使用许多磁盘搜寻-对于SSD来说并不是一个显着的好处，因为搜寻并没有太大的性能开销，因为它们与旋转磁盘。

回复@Matthew PK的评论。

当然，RAM中的位置A与RAM中的位置B一样快。那不是重点。我说的是这样一种情况：如果数据分散在许多页面中，则所需的所有数据都无法放入RAM。任何给定的页面可能只包含您感兴趣的少量数据。因此，当您访问A，B和其他行时，RDBMS必须继续加载和清除页面。那就是您受到性能损失的地方。

最好让每个页面都充满您感兴趣的数据，以希望随后的所有行请求都从RAM中的页面得到服务。使用聚簇索引是确保将数据分组到更少页面上的一种好方法。

是的，这绝对还是有道理的。您认为方法太低级了。SQL服务器（在一个非常 非常简单的解释）存储在B树架构集群数据。这允许基于聚簇索引键值进行快速数据检索。

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

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

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