如果数据库只有一次插入，那么索引每个可能的列组合是否很糟糕？

是的，它会影响初始计划编译时间，因为优化器将有许多额外的数据访问路径需要考虑。

既然您使用的是 SQL Server 2017，只需加载一次并运行报表，为什么不直接使用聚集列存储索引呢？

这似乎是您需要索引每个可能的列组合的理想解决方案。

列存储索引 - 概述

如果表中有 N 列，则每个可能的列组合都是 2^N-1（删除空集）。对于 10 列，这意味着 1023 个索引，对于 20 列，我们最终会得到高达 1048575 个索引。大多数索引永远不会被使用，但必须由优化器考虑。优化器可能会选择次优索引而不是更好的索引。我不会采取生成各种索引的路径，而是试图找出哪些索引实际上是有益的。

编辑更正的可能索引数

正如Jeff指出的那样，它甚至比 2^N（幂集）更糟糕，因为 (3,2,1) 明显不同于 (1,2,3)。对于 N 列，我们可以选择索引中的第一个位置，该索引包含 N 种方式的所有列。对于 N-1 种方式中的第二个位置，依此类推。因此，我们最终得到 N！全尺寸的不同索引。这些索引中没有一个被该集合中的另一个索引所包含。此外，我们不能添加另一个较短的索引，使其不被任何完整索引覆盖。因此索引的数量是 N!。因此，10 列的示例变为 10！= 3628800 个索引和 20 个（鼓）2432902008176640000 个索引。这是一个大得离谱的数字，如果我们在每一个 1 毫米的零件上放置一个点，那么一束光束需要 94 天才能通过所有点。所有和所有，不要;-)

不。

索引“所有内容”是不切实际的，但您可以索引其中的“大部分”。

事情就是这样。如果一个表有N列，那么可能的索引数是N!。假设一个表有 10 列，那么您不仅有10可能的索引，而且10!. 也就是说...... 3,628,800 ...... 在一张桌子上。这是大量的磁盘空间、磁盘 I/O、缓存和寻道时间。

为什么？几个原因：

• Lightwight 索引通常被缓存，这使它们变得快速。如果你有 300 万个，它们就不会被缓存。

• SQL 优化器可能会花费大量时间来决定使用哪个更好，尤其是在使用连接时。

• SQL 优化器可能会放弃使用综合算法，而尝试使用启发式算法。这可能“不太理想”。例如，PostgreSQL 对于“少于 8 个表查询”和“多于 8 个表查询”有不同的选项。

• 索引应该比堆轻。如果您正在索引所有内容，那么索引就会变得像堆一样重......这违背了索引的目的。

不，它可能不会对SELECT查询产生负面影响，但是

• 这将导致磁盘使用率高。
• 会大大增加INSERT成本。
• 您的大多数索引将永远不会被使用。
• 许多WHERE条件表达式仍然不会使用索引，主要是更复杂的。
• 所需索引的数量将随着列的数量呈指数增长。例如，如果您有 8 列，则所有可能的组合都需要 256 个索引。