我是否需要为所有可能的组合创建数据库索引？答案

【问题标题】：Do I need to create database indexes of all possible combinations?我是否需要为所有可能的组合创建数据库索引？
【发布时间】：2019-12-17 07:03:00
【问题描述】：

我的数据库表中有一个索引：

[ArcadeID] ASC,
[Published] ASC,
[AccessMode] ASC,
[ContentTypeID] ASC,
[SupportedDeviceTypes] ASC,
[LanguageID] ASC

最后三列ContentTypeID、SupportedDeviceTypes 和LanguageID 都是可选的。当应用某些过滤器时，在列出街机中的所有游戏时使用此索引。

如果这些列包含/排除在所有各种组合中，为了获得最大查询性能，我是否需要创建此索引的所有可能组合，或者上述索引是否已经涵盖所有组合？

【问题讨论】：

无论您在何处提出此问题，您都需要提供一些详细信息。发布的内容过于宽泛和模糊。
如果它是您尝试调整的特定查询，那么我们需要查询自身和查询计划（使用粘贴计划）。如果它更笼统，那么我们需要了解您的表中经常查询的什么，或者运行的频繁查询。在这两种情况下，都需要包含当前索引的表的完整 DDL。对于后者，您对系统的了解将难以轻松传达；您了解您的系统并且它的使用比我们好得多，因此您将应该知道索引中可能需要什么。
听起来您已经有了一个覆盖索引，尤其是有时仅包含最后三列。除非您遇到性能问题，否则我不愿意添加更多索引。
@TomGullen 如果您的查询只选择几列，您可以在 INCLUDE 子句中添加这些列。 CREATE INDEX idx_xxx ON table(ArcadeID] ASC, [Published] ASC, [AccessMode] ASC) INCLUDE（其他列）。这将节省昂贵的 PRIMARY KEY 查找。这将使索引成为您查询的覆盖索引。
@SeanLange 该索引实际上不是覆盖索引，除非所有被选择的列都是索引列或在 INCLUDE 子句中。

【解决方案1】：

搜索索引时，会遍历键的第一列，然后是第二列，依此类推。

您是说前 3 列是强制性的。如果您搜索完全匹配，那么对于这 3 列的不同顺序，您不需要不同的索引。但是，如果您使用通配符搜索（例如 AccessMode LIKE '[RW]'），那就很重要了。

对于可选列，顺序也很重要，但前提是到那时（在确定确切的 ArcadeID、Published 和 AccessMode 之后）选择仍然太大。

当您使用完全匹配搜索（如上所述）时，最好根据统计属性确定前 3 个必填列的顺序。应首先列出最具选择性的列，然后是下一个最具选择性的列。

【讨论】：