本文只讲最最平常最最简单的索引就是以create index ix on tx(abc);形式创建的索引而不讲位图索引反向键索引倒序索引基于函数的索引等等其实呢只要是基于B树的索引不管是在Oracle Mysql还是其它数据库中原理应当都是一样的
索引最重要的一个性质应该就是有序索引中的每一项是从左到右从小到大以严格的顺序排列好的
下面的讨论都以上面的索引ix(abc)为例
把这棵索引的叶子节点画到纸上大概是这样的
a a a an
b b b bn
c c c cn
上面这个×n的矩阵每一列代表了一条记录同时这一列记录也对应了表里的唯一一条记录当然在Oracle里对于nonunique索引需要补上rowid才是真正唯一的上面的索引相当于create unique index ix on tx(abcrowid); 我们把这个细节忽略掉
把每一列看作一个向量vi = (ai bi ci)
有序的含义就是
vi < vj iff i < j;
vi < vj这么定义
(ai < aj) or (ai = aj and bi < bj) or (ai = aj and bi = bj and ci < cj)
从这个基本性质我们可以得到一些其它性质(为了打字方便ai+k表示a(i+k)而不是a(i)+k)
) 如果ai ai+ …… ai+k 都是相等的那么
bi <= bi+ <= …… <= bi+k
) 如果ai ai+ …… ai+k是相等的而且bibi+ …… bi+k也是相等的那么
ci <= ci+ <= …… < ci+k
但是从 ai ai+ …… ai+k相等我们得不到
ci <= ci+ <= …… <= ci+k这个结论
索引相关的很多问题都和上面提到的这几个性质有关系
下面来看几个常见的查询:
q) select * from tx where a = :va and b = :vb;
q) select * from tx where b = :vb and c = :vc;
q) select * from tx where a = :va and c = :vc;
q) select * from tx where a = :va order by b;
q) select * from tx where a = :va order by b c;
q) select * from tx where a = :va order by c;
q) select * from tx where a = :va order by b c desc;
q) select * from tx where a = :va order by b desc c desc;
q) select * from tx where a = :va and b <= :vb
qa) select * from tx where a = :va and b >= :vb
qb) select * from tx where a = :va and c >= :vc
qc) select * from tx where a = :va and b >= :vb order by c
大家可以考虑一下这些查询各自会以怎样的方式执行不同查询之间有什么区别?
同样为什么在索引字段上作了函数运算之后索引不可用?
考虑下面这个语句:
select * from tx where f(a) = :vfa;
首先在字段 a上作了函数运算之后排序的规则是否仍旧一样? a < b 与 f(a) < f(b)是否等价?
其次就算f(a)和a的排序规则一样但是索引块中存的a 但是你传给它的是经过了函数运算的值:vfa 只有oracle知道函数f的反函数inv_f并在vfa上做inv_f(:vfa)计算之后才能通过索引的B树结果进行查找
当然现实中f可能不是显示的而是隐式的如传入参数和字段类型不匹配的情况下Oracle可能在字段上作函数运算从语句上可能看不出索引字段上被做了函数运算但Oracle内部已经在字段上运用了函数这样也会导致索引不可用这种情况下用hint强制使用索引也是没用的
通过dbms_xplandisplay_cursor可以或许可以查看到这种隐式类型转换
通过v$sql_bind_metadata应当可以查看到每个绑定变量的类型
通过v$sql_bind_capture这个视图甚至可以看到每个绑定变量具体的值不要把bind_capture和bind peek搞混哦而且这里bind_cature也不会每绑定一次变量就capture一次不然对执行量非常高绑定频繁的语句capture以同样频率进行的话开销可能还是有点大的
上面讲到了索引的有序性下面来讲讲索引另外一个有趣的性质其实我们完全可以把索引看作一张表这张表包含和主表一样多的记录(如果不考虑null)只不过每条记录只有主表的部分字段开个玩笑我们是不是可以把索引叫做有序视图呢?或者精确一点有序物化视图:)
那么我在执行一些查询的时候如果所有字段都包含在索引中是不是只要访问索引就可以了呢?
这些字段可以出现在select列表中where条件中order by字段中也可以出现在两个表连接时的连接条件中
那么根据业务的需求我们是不是可以设计或调整索引以减少对主表的访问呢?或者是不是可以适当的调整应用的设计或实现来满足索引呢?
同时考虑到索引的有序性是不是可以利用索引来避免排序呢?
当然我们不能忽略null的存在如果一条记录在索引中的所有字段上都是null的那么oracle是不会索引这条记录的比如如果记录ri的ai bi ci字段都是null的索引中是找不到这条记录的这会有什么问题呢?首先表中的记录和索引中的记录从数量上来说就不一样了
考虑一下Oracle会怎样执行下面这个查询:
select count(*) from tx;
这个呢hint起作用了吗?
select /*+ parallel(tx ) */ count(*) from tx;
大家可以测试一下怎样把count(*)这个操作并行化从这里或许可以得到一些Oracle怎么处理hint的提示
最后讲一下Oracle CBO计算索引访问成本的公式
cost =
blevel +
ceiling(leaf_blocks * effective index selectivity) +
ceiling(clustering_factor * effective table selectivity)
这个公式相信很多地方可以找到(我是从cost base oracle fundamentals这本书里copy出来的)简单说一下我自己对这个公式的理解
blevel是索引树的高度
leaf_blocks是索引的页子节点的个数
effective index selectivity (eis)怎么算呢?
还是举几个例子
where a = :va and b = :vb c = :vc
这里eis是 (selectivity a) * (selectivity b) * (selectivity c)
where a = :va and c = :vc
这里eis是 selectivity a
where b = :vb and c = :vc
这里eis是
where a = :va and b >= :vb and c = :vc
这里eis是 (selectivity a) * (selectivity range b)
就是说按索引字段的顺序第一个不在where条件中出现的字段或者第一个做了范围运算的字段之后出现的字段的selectivity是不能乘到effective index selectivity里去的
简单的说ceiling(leaf_blocks * effective index selectivity)表示的是Oracle需要访问的索引叶子节点的个数
clustering_factor表示的是按索引的顺序从头走到尾需要访问多少次数据块这里需要考虑到Oracle的一个优化如果连续n条记录在同一个表块中那么oracle认为只需要访问一次数据块
那么clustering_factor的值的范围就很容易确定了cf >= table blocks and cf <= rows in index
effective table selectivity这个计算就容易了把索引中所有字段的selectivity乘起来就可以了
如果查询中还有其它条件 比如 d = :vd and e = :ve 但是de这些字段又不在索引中那么在这些列上的过滤条件需要回表后把这些值取出来才能判断所以de这些列的selectivity是不能乘到effective table selectivity里去的
ceiling(clustering_factor * effective table selectivity)表示需要回表的次数
所以上面索引访问的cost就是走某个索引需要访问的数据块的个数
当然前面的讨论忽略了index skip scan这种情况因为本人对index skip scan也不是很明白
什么情况下会走skip scan?
select * from tx where a = :va and c = :vc 是不是会在c这个字段上也作一个skip scan呢?
同时也没有考虑in list iterate这些情况需要进一步研究
