主页 / dba / 问题 / 8496
Accepted
Matthew
Asked: 2011-11-29 11:36:53 +0800 CST

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

  • 772

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

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

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

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

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

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

sql-server clustered-index

3 个回答

  1. Best Answer

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

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

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

    • 35

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

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

    回复@Matthew PK 的评论。

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

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

    • 23

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

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

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

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

    • 13

相关问题