数据库索引：只选择！

Question

美好的一天，

我有大约4GB的数据，在大约10个不同的表中分开。每个表都有很多列，每列可以是查询中的搜索条件。我根本不是DBA，我对索引知之甚少，但我想尽可能加快搜索速度。重要的是，任何时候都不会有任何更新，插入或删除（表格每4个月填充一次）。是否适合在每一列上创建索引？记住：没有插入，更新或删除，只选择！ 另外，如果我可以将所有这些列整数而不是varchar，那么我的速度会有所不同吗？

非常感谢！

Answer 1

答案：不。分别索引每一列不是好设计。在许多情况下，索引需要包含多个列，并且针对不同的需求存在不同类型的索引。

其他答案中提到的调整向导是一个很好的第一个剪辑（特别是对于学习者）。

不要试图通过它猜测，或希望您了解复杂的分析 - 获取针对您的情况的建议。我们似乎有几个线程在这里非常活跃，特定情况和查询优化。

Answer 2

您是否看过运行Index Tuning Wizard?会根据工作量为您提供索引建议。

Answer 3

绝对不是。

您必须了解索引的工作原理。如果你有一个表，1000个记录，但它是一个BIT，并且可以有两个值中的一个，如果你只对该列和那个列进行索引，那么它将毫无价值，因为它没有足够的选择性。当您对列进行索引时，要非常了解将在表上执行哪些类型的选择。在列上创建索引时，该索引是否具有足够的选择性以使优化器有效使用？

到那时，您可能会发现一些精心挑选的复合索引将远远超过每列上许多单个索引的解决方案。黄金法则：如何查询数据库将决定如何制作索引。

Answer 4

两条缺失的信息：每列中有多少个不同的值，以及您正在使用的DBMS。如果您使用的是Oracle，并且每列的不同值少于几千，则可以创建位图索引。对于精确匹配，这些非常具有空间和执行效率。

否则，这是一个权衡：每个索引将添加与包含相同数据的单列名称大致相同的空间量，因此您基本上可以加倍（可能是2.5倍）您的空间需求。所以可能是10G，这不是很多数据。

然后问题是您的DBMS是否会有效地合并多个基于索引的选择。它很可能不会，除非你为你选择的每一列进行自连接。

最佳答案：在较小的数据集上尝试（这样您就不会花费所有时间来构建索引），看看它是如何工作的。

Answer 5

如果从表中选择一组列大于所选索引中列所覆盖的列，那么您将不可避免地在查询计划中产生书签查找，这是查询处理器必须检索非 - 使用关联的非聚集索引中叶子行的引用ID从聚簇索引中覆盖列。

根据我的经验，由于需要额外读取的数量以及必须单独解析聚集索引中的每一行这一事实，书签查找确实会破坏查询性能。这就是为什么我尝试尽可能地覆盖NC索引，这对于所需查询计划众所周知的小型表更容易，但是如果你有大量的表，其中包含大量具有任意查询的列，那么这可能不会可行的。

这意味着你只能使用任何类型的NC索引获得支持，如果索引覆盖，或选择足够小的数据集以降低书签查找的成本 - 事实上，你可能会发现如果与聚簇索引扫描相比成本过高，查询优化器甚至不会查看索引，而聚簇索引扫描中所有列都已可用。

因此，除非您知道索引将优化给定查询的结果，否则创建索引没有意义。因此，索引的值与它可以针对给定表优化的查询的百分比成比例，这只能通过分析正在执行的查询来确定，这正是索引优化向导为您所做的。 / p>

总结如下：

1）不要索引每一列。这是经典的过早优化。您无法提前为所有可能的查询计划优化带有索引的大型表。

2）在通过索引优化向导捕获并运行基本工作负载之前，不要索引任何列。此工作负载需要代表应用程序的使用模式，以便向导可以确定哪些索引实际上有助于查询的性能。