两列的聚集索引答案

【问题标题】：Clustered index on two columns两列的聚集索引
【发布时间】：2011-07-22 17:53:49
【问题描述】：

我有一个多对多表，比如说：

PersonJob(personId,jobId)

使用聚集索引 (personId,jobId)。

问题是：

如果在 SQL 中的某个地方，我会进行如下查询：

SELECT *
FROM PersonJob JOIN Job ON PersonJob.jobId = Job.jobId
.......

它会利用聚集索引在 PersonJob 表中查找具有特定 jobId 的记录吗？或者我会更好地在 PersonJob 表的 jobId 列上创建新的非聚集非唯一索引？

谢谢帕维尔

【问题讨论】：

聚簇索引的叶页实际上包含行数据——对于具有聚簇索引的表，数据行存储在其中。因此，除非有一个包含查询的所有相关列的非聚集索引（称为覆盖索引），否则每个查询都必须在某个时间点访问聚集索引。
如果您想了解有关索引的更多信息：请查看我的SQL Indexing tutorial (also for SQL Server)。 multi-column indexes 上的页面解释了为什么您的查询无法有效利用您拥有的（聚集）索引。

标签： sql-server indexing clustered-index

【解决方案1】：

您不会从聚集索引中获得任何优势，并且您的查询仍需要扫描 PersonJob 表的所有行。

如果您的聚集索引（jobID、personId）中的列颠倒了，那么您将利用索引。考虑到聚集索引根据构成索引的列的值对表中的实际行进行排序。因此，通过 (personId, jobID) 上的聚集索引，您可以将具有相同 personId 的所有行“分组”在一起（按 jobID 的顺序），但具有相同 jobID 的行仍然分散在表周围。

【讨论】：

我这么想。但是当我运行“估计的执行计划”时，它显示该索引无论如何都会被使用。
它显示了什么 - 聚集索引搜索或聚集索引扫描（类似于表扫描）？如果您对如何理解执行计划感兴趣，请查看此链接：stackoverflow.com/questions/758912/…
感谢资源。现在我玩过 indexex 的不同组合，@Damien_The_Unbeliever 写的似乎部分正确。当我在 jobID 列上添加单列索引时，它取代了之前对聚集索引的扫描。该步骤的成本从 45% 下降到 10%，SQL Server 弹出信息窗口中扫描的行数也从 11.000 减少到 10 :) - 10 是查询返回的虚构作业数 :) 无论如何，在做出任何结论之前，我'将阅读有关索引以及如何分析执行计划的更多信息。非常感谢。