Sql 覆盖索引的有用性

我有一个对多个表执行联接的查询。我在表的外键上有非聚集索引，在主键上有聚集索引。在分析查询计划时，我发现查询优化器在所有表上选择聚集索引扫描，或者在某些情况下结合非聚集索引扫描和键查找来获取其他非键列。为了解决这个问题，我在非聚集索引中包含（涵盖）了这个查询中所需的非键列。因此，我可以看到非聚集索引查找/扫描按预期执行

现在我的问题是，如果有其他查询需要许多其他非键列作为结果集的一部分，那么我可能最终会向非聚集索引添加（包括）所有列，以提高所有查询的性能。这是个好主意吗

---

谢谢。

这非常有助于理解您的用法。为您可能查询的所有内容添加索引将非常容易，但与所有内容一样，这是一种折衷。每个索引都会耗费您的时间和存储空间，因此很可能会减慢插入/更新的速度，而且索引越多，成本越高

如果您的使用非常倾向于读而不是写，那么一切都很好，您需要做的就是支付一些存储费用。如果您也需要良好的写操作性能，那么您真正能做的就是了解您的应用程序并为最重要的内容编制索引

---

我强烈推荐“inside sql server”系列书籍（Kalen Delaney et al）-需要大量阅读，但我保证它们将帮助您理解所做的权衡。

听起来您包含了WHERE子句所需的列，因此您得到了索引查找

您还可以包括选择列表中的列，这会给您带来不同的好处。如果索引包含查询所需的所有字段，包括选择列表，那么查询结果可以直接从索引中返回，而不必返回到表记录

当然，更新、插入和删除操作还包括建立索引的额外成本

您可以运行SQLServerManagementStudio工具>SQLServerProfiler来获取当前数据库活动的示例。然后，您可以将其提供给工具>数据库引擎优化顾问。如果您有大量的插入和更新活动，Tuning Advisor可能会建议删除一些索引。如果您的活动主要是SELECT语句，则可能会建议附加索引

我发现数据库引擎优化顾问经常建议在许多列上覆盖索引，如您所描述的。在这个问题上，我有时会同意它的建议，但通常会将索引限制在键和条件列，除非特定查询存在特定的性能问题