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

Question

在设计 SQL 服务器数据架构和后续查询、sproc、视图等时，对于明确部署在 SSD 平台上的数据库设计，集群索引和磁盘上数据顺序的概念是否有意义？

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

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

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

我最初的想法是，这并不是因为“有序数据”的想法不适用于 SSD 存储和搜索/检索优化。

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

Answer 1

再问自己一个问题：如果整个数据库都在内存中而我永远不必接触磁盘，我是想将数据存储在有序的 B 树中，还是想将数据存储在无序的堆中？

这个问题的答案将取决于您的访问模式。在大多数情况下，您的访问需要单行查找（即查找）和范围扫描。这些访问模式需要 B 树，否则效率低下。其他一些在 DW 和 OLAP 中很常见的访问模式总是对整个表进行端到端的聚合，并且它们没有从范围扫描中受益。当您进一步钻研时，其他要求就会浮出水面，例如插入和分配到堆中的速度与 B 树的速度可能会在大型 ETL 传输作业中发挥作用。但大多数时候，答案实际上归结为一个问题：你是搜索还是范围扫描？绝大多数时候答案是肯定的。因此，设计需要聚集索引的次数太多了。

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

Answer 2

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

但是你是对的，聚集索引的另一个好处——按顺序读/写相关数据而不是多次磁盘搜索——对 SSD 来说并不是一个显着的好处，在 SSD 中，搜索并不是一个巨大的性能开销，因为它们带有旋转磁盘。

回复@Matthew PK 的评论。

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

最好让每个页面都充满您感兴趣的数据，希望所有后续行请求都来自 RAM 中的页面。使用聚集索引是确保将数据组合到更少页面上的好方法。

Answer 3

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

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

所以答案是肯定的，即使在 SSD 上，在表上创建聚集索引仍然有意义。这一切都基于 SQL Server 必须筛选多少数据才能获得结果数据。使用聚集索引查找，它被最小化。

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