非聚集覆盖索引列选择规则答案

【问题标题】：Non Clustered Covering Index Column Selection Rules非聚集覆盖索引列选择规则
【发布时间】：2012-01-11 10:05:38
【问题描述】：

我有一个包含大约 19 列的表，其中包含合理的大量数据，并且主要用于查询以使用基于不同 where 子句的 select 语句检索数据。由于该表主要用于查询数据，因此我考虑根据查询中使用的不同 where 子句创建非聚集索引。此外，所有 get 查询都将表中的所有列作为选择列表的一部分返回。根据以上信息，我有两个选择索引的问题：

让我们假设我们有以下查询的 SP：
```
where [col_a] = {value} and [col_b] = {value}

      [col_b] = {value} and [col_a] = {value}

      [col_a] = {value} and [col_c] = {value} and [col_d] = {value}

      [col_a] = {value} and [col_c] = {value}
```
我在表上创建了以下非聚集索引

[col_a] 和 [col_b] --> 第一个 SP 是否仍然使用这个索引作为订单颠倒了

[col_a] and [col_c] and [col_d] --> 最后一个SP会使用这个索引吗因为前两列与顺序匹配

另外，我们是否应该继续尝试根据表上的 get SP 的过滤器/连接子句定义非聚集索引？
由于所有 SP 中的选择列表返回整个列列表，我将表的所有列添加为非聚集索引（覆盖索引）中的包含列以避免书签查找。这种方法正确吗？由于我们将所有表列存储为索引定义的一部分，在这种情况下会产生什么空间影响？

【问题讨论】：

标签： sql indexing

【解决方案1】：

[col_a] 和 [col_b]
第一个 SP 是否仍会使用此索引作为顺序颠倒了

是的 - 如果您指定 both 列，并且您的索引包含这两列作为其列列表中的前两列，则可以使用索引，并且顺序并不重要。

如果你有一个索引(col_a, col_b)，如果你指定它就可以使用：

就col_a
col_a 和 col_b（顺序无关）

但它不能用于仅指定col_b（但不是col_a）的查询。为了考虑使用，最左边的 n 列 (n >= 1) 必须以任意顺序使用/定义。

[col_a] 和 [col_c] 和 [col_d]
最后一个 SP 会使用这个索引吗因为前两列与顺序匹配

是的 - 正如我上面提到的，如果使用最左边的 n 列，则可以考虑索引，所以如果你指定总共三个中的前两个 - 你很好。

警告：仅仅因为您指定了正确的列并不一定意味着最终将实际使用索引。查询优化器将考虑使用 - 但如果这样更方便/更快，它可能仍会采用另一种方式。

【讨论】：

【解决方案2】：

WHERE 子句中的顺序与此处无关。所以，是的，这两个索引将完美地服务于所有四个示例。

至于帮助 JOIN 的索引，是的，一般建议。

您可能会发现，如果您创建的索引非常适合您曾经使用的每个连接，那么您就有很多索引。这可能会导致写入表时出现性能问题。在这种情况下，您可能会发现一小组索引不适合您的 JOIN 和 WHERE 子句，但足够好，您可以只用这几个来管理。这是你需要平衡自己的妥协。

最后，请注意某些 RDBMS 可以使用索引合并。这可能意味着多个简单或更简单的索引几乎与复合/覆盖索引一样好。但在大多数情况下，在考虑索引什么时，您确实需要同时考虑 WHERE 子句和 JOIN。

这是因为索引的主要特征是记录的顺序。理想的情况是将所有感兴趣的记录放在一个顺序块中（在您的 WHERE 子句和 JOIN 将其过滤掉之后），并以对后续 JOIN 或 GROUP BY 友好的顺序排列。实际上，您的目标是使数据位于尽可能少的顺序集群中，并尽可能地符合顺序。然后让 RDBMS 优化器完成剩下的工作 :)

【讨论】：