http://msdn.microsoft.com/zh-cn/library/aa933131(v=sql.80).aspx
“聚集索引确定表中数据的物理顺序。 “
在物理磁盘平台上，考虑到它们的设计对我来说很有意义，因为对数据进行物理扫描以检索“顺序”行比在表中查找更有效。
在SSD平台上，所有数据读取访问都使用相同的查找。在位存储在同一块硅片的意义上，没有“物理顺序”的概念，数据读取也不是“顺序的”。
因此，在设计应用程序数据库的过程中，与该平台相关的聚簇索引考虑因素是什么？数据”不适用于SSD的存储和查找/恢复优化。
编辑：我知道SQL Server会创建一个，我只是在思考在设计时考虑一下是否有意义/优化。
#1 楼
问自己另一个问题：如果整个数据库都在内存中，而我又不必接触磁盘，我是否要将数据存储在有序的B树中还是要将数据存储在无序的堆中？ >这个问题的答案取决于您的访问方式。在大多数情况下，您的访问需要单行查找（即搜索）和范围扫描。这些访问模式需要B树，否则效率低下。 DW和OLAP中常见的其他一些访问模式始终始终在整个表的端到端进行聚合，并且它们不会从范围扫描中受益。随着您进一步钻研，其他需求也逐渐浮出水面，例如插入和分配到堆与B-Tree的速度可能对大量的ETL传输作业起作用。但是大多数时候，答案实际上都归结为一个问题：您是寻找还是进行范围扫描？答案是“是”。因此，绝大多数的设计需要一个聚集索引。在64Gb RAM扫描中大发横财...
评论
即使在内存中，在基堆中查找行的开销也总是比直接在搜索中检索行的开销高。不仅从内存访问的位置出发，而且从涉及的大量指令中（查找基本上是一个联接，具有所有联接运算符机制）。
–雷木斯·鲁萨努（Remus Rusanu）
2011-11-28 22:47
#2 楼
如果使用精心选择的聚集索引，则更有可能在较少的数据页中获得所需的所有相关数据。也就是说，您可以在更少的内存中保存所需的数据。不管您使用旋转磁盘还是固态硬盘，这都将带来好处。 -对于SSD来说并不是一个显着的优势，在这种情况下，寻道不会像旋转磁盘那样具有巨大的性能开销。 br />当然，RAM中的位置A与RAM中的位置B一样快。那不是重点。我说的是这样一种情况：如果数据分散在许多页面中，则所需的所有数据都无法放入RAM。任何给定的页面可能只包含您感兴趣的少量数据。因此，当您访问A，B和其他行时，RDBMS必须保持加载和清除页面。这就是性能损失的地方。最好让每个页面都充满您感兴趣的数据，希望所有后续的行请求都从RAM中的页面提供。使用聚簇索引是确保将数据分组到更少页面上的一种好方法。
#3 楼
是的，这绝对还是有道理的。您认为方法太低级了。 SQL Server（在非常简化的解释中）将群集数据存储在B树体系结构中。这允许基于聚簇索引键值进行快速数据检索。堆（无聚簇索引）没有数据的顺序。这里要考虑的最重要的事情是，在堆中，数据页未在链接列表中进行链接。在SSD上。这完全取决于SQL Server必须筛选多少数据才能获得结果数据。使用群集索引查找，可以将其最小化。
参考：http://msdn.microsoft.com/zh-cn/library/ms189051.aspx
评论
将有一个聚集索引。关键是，在SSD平台上寻求解决方案是否重要
–马修
2011-11-28 19:54
是的，寻找问题。无论使用哪种介质，3读相对于300读都更快。
–托马斯·斯金格
11年11月28日在19:56
评论
有关此一般领域的一些论文（并非特定于您的问题）查询优化器是否需要支持SSD？固态驱动器的查询和查询处理技术