sql-server – 使用SSD时,数据库设计中聚集索引的概念是否合理？

在设计SQL服务器数据模式和后续查询,sprocs,视图等时,对于明确部署在SSD平台上的DB设计,是否考虑了磁盘上的聚簇索引和数据顺序的概念？

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

在物理磁盘平台上,考虑它们的设计对我来说是有意义的,因为检索“顺序”行的数据的物理扫描可能比通过表搜索更高效.
在SSD平台上,所有数据读取访问都使用相同的搜索.没有“物理顺序”的概念,并且在位存储在同一块硅上的意义上,数据读取不是“顺序的”.

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

我最初的想法是,这不是因为“有序数据”的概念不适用于SSD存储和搜索/回溯优化.

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

解决方法

这个问题的答案取决于您的访问模式.在大多数情况下,您的访问需要单行查找(即搜索)和范围扫描.这些访问模式需要B树,否则它们效率低下. DW和OLAP中常见的一些其他访问模式总是在端到端的整个表上进行聚合,并且它们不会从范围扫描中受益.当你进一步钻取其他需求时,就像插入和分配到堆中的速度相比,B-Tree可能会对巨大的ETL传输作业起作用.但大多数时候答案真的归结为一个问题：你是寻求还是范围扫描？绝大多数答案都是肯定的.因此,绝大多数时候设计需要聚集索引.

换句话说：只是因为以随机顺序从磁盘读取它是便宜的并不意味着你可以在64Gb RAM扫描富矿中丢弃你的TLB和L2线路……

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!