我有一个查询在多个表上执行连接。我在表的外键和主键上的聚簇索引上有非聚簇索引。在分析查询计划时，我发现查询优化器正在所有表上选择聚簇索引扫描，或者在某些情况下，将非聚簇索引扫描和键查找组合在一起以获取其他非键列。为了解决这个问题，我在非聚集索引中包含了（覆盖）此查询中所需的非键列。因此，我可以看到非聚集索引搜索/扫描按预期执行。涵盖索引的用处
现在我的问题是，如果我有其他查询需要许多其他非键列是结果集的一部分，那么我可能会最终将所有列添加（INCLUDING）到非聚集索引来改善所有查询的性能。这是个好主意吗？
谢谢。
它非常了解您的使用情况。为所有可能查询的内容添加索引是非常容易的，但与其他所有内容的折衷相比，这是非常容易的。每个索引都会花费你的时间和存储 - 所以它可能会减慢你的插入/更新速度，而且你索引得越多，这个成本就越高。
如果您的使用非常有利于读写，那么一切都很好，您只需支付一些存储费用即可。如果你也需要体面的写作表现，那么你所能做的就是理解你的应用程序并为你的最重要的东西编制索引。
我强烈推荐“内部sql server”系列丛书（Kalen Delaney et al） - 大量阅读材料，但我保证他们会帮助您理解您所做的权衡。
这听起来像你包含了你的WHERE子句所需的列，并且你得到了索引查找的结果。
您还可以包含在您的SELECT列表中的列，这会给您带来不同的好处。如果您的索引包含查询所需的所有字段（包括SELECT列表），那么查询结果可以直接从索引中返回，并且永远不必返回表格记录。
当然，UPDATE，INSERT和DELETE操作会包含索引构建的额外成本。
您可以运行SQL Server Management Studio工具> SQL Server事件探查器以获取当前数据库活动的示例。然后，您可以将其提供给工具>数据库引擎优化顾问。如果您有很多INSERT和UPDATE活动，Tuning Advisor可能会建议删除一些索引。如果您的活动主要是SELECT语句，则可能会建议其他索引。
我发现数据库引擎优化顾问通常建议覆盖多个列上的索引，如您所描述的。我有时会根据这个问题提出建议，但通常会将索引限制在关键字和条件列中，除非特定查询存在特定的性能问题。