SQL Server:索引的类型如何影响联接的性能?

如果我遍历并创建只包含联接中涉及的列的聚集索引,而不包含其他任何列,我会获得任何性能吗?

我不明白。聚集索引的要点是,它随后会围绕索引对磁盘上的数据进行排序(因此,为什么您只能使用该索引),因此,如果您的连接数据也没有按照这些精确的列进行排序,我认为这不会有任何区别。另外,通过将可能发生更改的数据(而不是键)放入聚集索引中,可以使事情更有可能需要定期重建,从而降低整个数据库的速度。

抱歉,如果这听起来是一个愚蠢的问题,但您是否尝试通过索引优化向导运行查询?一点也不简单,但我过去已经有了一些不错的改进。

除了加雷斯·索尔的回答之外,还有一个小小的澄清:

非聚集索引重复 包含字段,带有 指向的指针 排 有这个价值的。

指向实际数据值的指针是集群键中的列(或列集)。

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

此“查找指针是群集键”功能自版本7以来一直在SQL Server中,作为 Kim Tripp will explain in great detail here :

什么是聚集索引?

在SQL Server 7.0及更高版本中, 内部依赖于 群集键已更改。(是的,它是 重要的是要知道事情发生了变化 7…为什么?因为还有 有些人不知道 认识到变革的根本性 发生在内部(与 在SQL Server 7.0中)。

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

只有一个聚集索引-这是控制表在磁盘上/内存中的物理存储的内容。

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

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

在大多数情况下,您只需使用数据库引擎优化顾问——它提供的建议非常适合您。

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

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

如果可能,有一个索引,其中没有不必要的字段。添加的每个字段都会使单个索引记录变大,每个索引记录越小,在每个页面中获得的信息就越多。每页中的索引项越多,进入磁盘的次数就越少。

聚集索引 -这意味着表按索引中指定的顺序布局,这意味着您将从indexfield=3的表中获得更好的select*性能。除非您选择了大量的大数据项,否则不需要这样做。