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

Question

我正在开发一个需要大量选择查询的报告系统，但它基于只填充一次的数据库。数据库管理系统是 Microsoft SQL Server 2017。可能有更好的方法来设计这样的系统，但让我们从理论上来解决这个问题。

理论上来说：

1. 如果我们有一个非常大的数据库（多个表上的 150M+ 行）
2. 我们可以假设数据库只会填充一次。

索引每个可能的列组合是否会对选择查询产生负面性能影响？

Answer 1

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

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

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

列存储索引 - 概述

Answer 2

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

编辑更正可能索引的数量

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

Answer 3

不。

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

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

为什么？几个原因：

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

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

• SQL 优化器可能会放弃使用综合算法，而尝试使用启发式算法。这可能“不是最佳的”。例如，PostgreSQL 对“小于 8 表查询”和“大于 8 表查询”有不同的选项。

• 索引应该比堆轻。如果您正在索引所有内容，那么索引会变得和堆一样重……这与索引的目的背道而驰。