1

如果我试图从查询中挤出最后一滴性能，那么我的联接使用这些类型的索引会产生什么影响。

  • 聚集索引。
  • 非聚集索引。
  • 具有可能不参与联接的额外列的聚集或非聚集索引。

如果我通过并创建只包含我的联接中涉及的列而不包含其他任何内容的聚集索引，我会获得任何性能吗？

（我意识到我可能必须从另一个索引中移动聚集索引（使该索引成为非聚集索引），因为它只能有一个。）

4

4 回答 4

2

除了 Gareth Saul 的回答之外，还有一个小小的说明：

非聚集索引重复包含的字段，并带有指向具有该值的行的指针。

这个指向实际数据值的指针是集群键中的列（或列集）。

这就是为什么您应该尝试保持集群密钥小而静态的主要原因之一 - 小，否则您将浪费大量空间，在磁盘和服务器的 RAM 中，并且是静态的，否则您将不得不更新如果您的值发生变化，不仅是您的集群索引，还包括您的所有非集群索引。

这种“查找指针是群集键”功能自 SQL Server 版本 7 起就已存在，正如Kim Tripp 将在此处详细解释的那样：

什么是聚集索引？

在 SQL Server 7.0 和更高版本中，群集键的内部依赖项已更改。（是的，重要的是要知道在 7.0 中发生了变化……为什么？因为仍然有一些人没有意识到 SQL Server 7.0 的内部结构（对于集群键）是如何发生根本性变化的）。

改变的是集群键被用作非集群索引的“查找”值。

于 2010-01-13T14:31:07.913 回答
1

你只会得到一个聚集索引——这是控制表在磁盘/内存中的物理存储。

非聚集索引重复包含的字段，并带有指向具有该值的行的指针。在连接中使用的列上建立索引应该可以提高性能。您可以通过在索引中使用“包含列”来进一步优化 - 这会将行信息直接复制到索引中，这可以消除必须查找行本身才能执行选择的性能损失。

注意连接发生的顺序很有用——索引中的列顺序应该与此匹配。请记住，SQL 引擎可能会在内部优化和重新排序您的查询 - 分析可能会有所帮助。

在大多数情况下，您可以只使用数据库引擎优化顾问 - 它提供的建议非常准确。

于 2010-01-13T14:12:11.693 回答
1

如果可以，最好的选择是使用包含所有联接元素的非聚集索引，如果可能，还包括您选择的字段。

这将创建一个跨越索引，这意味着 SQL 需要执行的所有字段都在一个索引上。

如果可能的话，有一个索引，其中没有 unnessasery 字段。添加的每个字段都会使单个索引记录更大，每个索引记录越小，您在每个页面中获得的越多。您在每个页面中获得的索引项越多，您访问磁盘的次数就越少。

聚集索引- 意味着表按索引中指定的顺序排列，这意味着您将获得更好的性能 select * from TABLE where INDEXFIELD = 3. 除非您选择大量大数据项，否则这不应该是必需的.

于 2010-01-13T14:16:39.377 回答
1

如果我通过并创建只包含我的联接中涉及的列而不包含其他任何内容的聚集索引，我会获得任何性能吗？

不像我理解的那样。聚集索引的重点是，它会围绕该索引对磁盘上的数据进行排序（因此为什么只能拥有一个），所以如果您的连接数据也没有按这些确切的列排序，我不会认为它会有所作为。另外，通过将可能更改的数据（而不是键）放入聚集索引中，您更有可能需要定期重建事物，从而减慢整个数据库的速度。

抱歉，如果这听起来是个愚蠢的问题，但是您是否尝试过通过索引调整向导运行查询？无论如何都不是万无一失的，但过去我已经有了一些不错的改进。

于 2010-01-13T16:49:07.260 回答