mil*_*lan 4 oracle relational-database compound-index indices
我被告知并在任何地方阅读它(但没有人敢解释为什么)当在多列上编写索引时,出于性能原因,我应该将最具选择性的列放在第一位.这是为什么？这是一个神话吗？
使用索引时可以省略从右到左的列,即当您有索引时col_a, col_b可以使用它WHERE col_a = x但不能使用它WHERE col_b = x.
想象一下,有一本电话簿按名字排序,然后按姓氏排序.
至少在欧洲和美国,名字的选择性比姓氏低得多,所以查找名字不会使结果集缩小很多,所以仍然会有很多页面要检查正确的姓氏.
我应该把最具选择性的专栏放在首位
根据Tom的说法,列选择性对使用索引中所有列的查询没有性能影响(它确实影响了Oracle压缩索引的能力).
这不是第一件事,它不是最重要的事情.当然,这是需要考虑的事情,但在宏观方案中相对较远.
在某些奇怪的,非常特殊和异常的情况下(如上面的数据真的完全偏斜),选择性很容易然而不管它们是什么,它们是
a)非常罕见的b)真正依赖于运行时使用的值,因为所有倾斜的查询都是
所以一般来说,看看你有的问题,尽量减少你需要的索引.
在考虑索引中的位置时,连接索引中列中的不同值的数量不相关.
但是,在决定索引列顺序时,这些注意事项应该排在第二位.更重要的是确保索引对许多查询有用,因此列顺序必须反映查询的where子句中这些列的使用(或缺少这些列)(由AndreKR说明的原因).
你如何使用指数 - 这是决定时的相关指标.
在所有其他条件相同的情况下,我仍然会将最具选择性的列放在首位.感觉很对......
更新: 汤姆的另一个引用(感谢米兰找到它).
在Oracle 5中(是的,版本5!),有一个参数可以将最具选择性的列放在索引中.
从那时起,将最具辨别力的条目放在索引中的第一个并不会使索引更小或更有效.它似乎会,但它不会.
使用索引键压缩,有一个令人信服的论据可以采用另一种方式,因为它可以使索引更小.但是,它应该由您使用索引的方式驱动,如前所述.