我已经读过（至少Oracle）数据库中的正常索引基本上是B树结构，因此存储处理适当根节点的记录。记录'小于'的根被迭代地存储在树的左侧部分，而大于'根的记录被存储到右侧部分。正是这种存储方法通过树遍历有助于更快的扫描，因为深度和广度都会降低。
但是，在创建索引或进行where子句的性能调优时，大多数指南都会首先说明要考虑等式(IN or = clause)的列的优先级，然后单独移动到带有不等式子句的列。 (NOT IN, <>)。这个建议的原因是什么？如果使用树遍历来预测给定值不像预测给定值那样容易存在是不可行的吗？
索引不能用于否定吗？
答案 0 :(得分：5)
问题在于索引中的位置。如果您有两列，其中col1中的字母和col 2中的数字，则索引可能如下所示：
Ind col1 col2
1 A 1
2 A 1
3 A 1
4 A 2
5 B 1
6 B 1
7 B 2
8 B 3
9 B 3
10 C 2
11 C 3
（ind是索引中的位置。记录定位器被省略。）
如果您正在寻找col1 = 'B'，那么您可以找到位置5然后扫描索引直到位置9.如果您正在寻找col1 <> 'B'，那么您需要找到第一条记录不'B'扫描并重复以后的第一条记录。 IN和NOT IN会使情况变得更糟。
另一个因素是，如果相对少数记录满足相等条件，则几乎所有记录都将失败 - 并且当几乎所有记录都需要读取时，索引通常无用。有时候例外的是聚簇索引。
Oracle比大多数数据库具有更好的索引优化 - 它将从不同位置开始进行多次扫描。即便如此，对于指数而言，不平等通常也不那么有用。