多列索引列顺序

Question

人们告诉我并到处读到它（但没有人敢解释为什么），当在多个列上构建索引时，出于性能原因，我应该将最具选择性的列放在第一位。这是为什么？这是一个神话吗？

Answer 1

我应该把最具选择性的列放在第一位

据汤姆说, ，列选择性对于使用索引中所有列的查询没有性能影响（它确实影响 Oracle 压缩索引的能力）。

这不是第一件事，也不是最重要的事情。当然，这是需要考虑的事情，但在宏伟的计划中它相对较远。

在某些奇怪的、非常奇特的和异常的情况下（比如上面的数据完全倾斜的情况），选择性很容易产生影响，但是，它们是

a）非常罕见的b）真正取决于运行时使用的值，因为所有偏斜的查询都是

所以总的来说，看看你有的问题，尝试根据这些问题最小化你需要的索引。

在考虑索引中的位置时，串联索引中列中的不同值的数量无关。

然而，在决定索引列顺序时，这些考虑因素应该排在第二位。更重要的是要确保索引对许多查询有用，因此列顺序必须反映查询的 where 子句中这些列的使用（或缺少这些列）（原因由 AndreKR 说明）。

如何使用索引——这是做出决定时相关的内容。

在所有其他条件相同的情况下，我仍然会将最具选择性的列放在第一位。就是感觉很对...

更新： 汤姆的另一​​句话 （感谢米兰找到它）。

在Oracle 5（是的，版本5！）中，有一个论点是将最选择性的列放在索引中。

从那时起，将最具区别的条目放在索引中并不是真的会使索引较小或更有效。看起来好像会，但其实不会。

使用索引密钥压缩，有一个令人信服的论点可以另一种方式，因为它可以使索引较小。但是，如前所述，它应该由您使用索引的方式驱动。

Answer 2

您可以从右到左使用索引时，即当你有col_a, col_b索引，你可以在WHERE col_a = x使用它省略列，但你不能在WHERE col_b = x使用它。

想象有一个由名字的然后的由姓氏。

排序的电话簿

至少在欧洲和美国的名字比姓低得多的选择性，因此要查找的第一个名字不会太大缩小结果集，所以仍然会有很多的网页，以检查正确的姓氏。

Answer 3

列的索引中的排序应当由你的查询确定，并且不会有任何选择性的考虑。如果您有（A，B，C）的索引，并且大部分的单个列的查询是针对C列，接着，然后把它们放在C，A，B的最佳效率的指标定义的顺序。甲骨文倾向于使用用于查询的索引的前缘，但可在称为跳跃扫描效率较低的访问路径中使用的其它列在索引中。

Answer 4

在更具选择性的是索引，最快的研制。

只要想象电话簿：您可以通过姓氏找人大多是快。但是，如果你有很多的人用相同的名字，你将持续更多的时间通过看名字每次要找的人。

所以，你必须首先给最有选择性的列，以避免尽可能多的这个问题。

此外，则应确保您的查询使用正确这些“选择性指标分析”。