在设计sql服务器数据模式和后续查询,sprocs,视图等时,对于明确部署在SSD平台上的DB设计,是否考虑了磁盘上的聚簇索引和数据顺序的概念？
http://msdn.microsoft.com/en-us/library/aa933131(v=sql.80).aspx
“聚簇索引确定表中数据的物理顺序.”
在物理磁盘平台上,考虑它们的设计对我来说是有意义的,因为检索“顺序”行的数据的物理扫描可能比通过表搜索更高效.
在SSD平台上,所有数据读取访问都使用相同的搜索.没有“物理顺序”的概念,并且在位存储在同一块硅上的意义上,数据读取不是“顺序的”.
那么,在设计应用程序数据库的过程中,是否与此平台相关的聚集索引考虑？
我最初的想法是,这不是因为“有序数据”的概念不适用于SSD存储和搜索/回溯优化.
编辑：我知道sql Server会创建一个,我只是在思考在设计/优化过程中考虑它是否有意义.
解决方法
问自己另一个问题：如果整个数据库都在内存中而我从不需要触摸磁盘,我是否要将数据存储在有序的B树中,或者我是否要将数据存储在无序堆中？
这个问题的答案取决于您的访问模式.在大多数情况下,您的访问需要单行查找(即搜索)和范围扫描.这些访问模式需要B树,否则它们效率低下. DW和OLAP中常见的一些其他访问模式总是在端到端的整个表上进行聚合,并且它们不会从范围扫描中受益.当你进一步钻取其他需求时,就像插入和分配到堆中的速度相比,B-Tree可能会对巨大的ETL传输作业起作用.但大多数时候答案真的归结为一个问题：你是寻求还是范围扫描？绝大多数答案都是肯定的.因此,绝大多数时候设计需要聚集索引.
换句话说：只是因为以随机顺序从磁盘读取它是便宜的并不意味着你可以在64Gb RAM扫描富矿中丢弃你的TLB和L2线路……
