我的 like '%VALUE%' 走了索引

husthxd

参考:
http://www.itpub.net/282230.html

biti_rainy

INDEX  fast  full  scan 和  index  range  scan 根本就是不同的概念，你需要先把原理弄清楚再来看表象

index  range scan 是 根据叶子节点的顺序去寻找数据，数据出来和索引顺序是一致的排好顺序的，一次读一个索引block和一个数据block

index  fast  full  scan 是根据索引 segment 的 extent 去搜索的，这个跟 FTS 的原理类似，不过 table  segment 换成了 index  segment ,一次读可以是连续的多个 index  block ，这样出来的数据顺序和 索引顺序并不一致。

而我们通常说的利用不上索引 指的 是 index  range scan  or   other  index  scan ,不是  index  fast  full scan  。
index  fast  full  scan 的前提是，数据肯定在索引中有（比如not null 的字段，或者复合索引，bitmap索引等），然后 索引 segment比表 segment小，通过索引segment 能得到所需要数据，而不用去读 任何表的block，这样 IO 将减少。

foreverlee

多谢楼上两位

xzh2000

最初由 foreverlee 发布
[B]

偷偷问一句： 我听人说 where column like '%%'这种查询方式会导致索引失效。
可是我的实验证明索引不会失效. [/B]

晕,无论如何,index range都比index full scan或fast index full scan要快。

biti_rainy

最初由 xzh2000 发布
[B]

晕,无论如何,index range都比fast index full scan要快。 [/B]

这个…… 你这等于是说 麻雀肯定比鲤鱼游泳要快

不同行为方式和不同目标的两个东西能这么比较吗？

xzh2000

最初由 biti_rainy 发布
[B]

这个…… 你这等于是说 麻雀肯定比鲤鱼游泳要快

不同行为方式和不同目标的两个东西能这么比较吗？ [/B]

select count(*) from .... where object_name like '%xxxxx%';
select count(*) from .... where object_name like 'xxxxx%';

可楼主确实是这样问过的,range index与fast full index scan谁快?
假如返回的结果是相同的,
一个是fast full index scan,一个是index range,由于可以执行fast full index scan,那在index range 中,这个SQL也可以不用访问表而可以直接得到结果,没有跑题吧。

biti_rainy

最初由 xzh2000 发布
[B]

select count(*) from .... where object_name like '%xxxxx%';
select count(*) from .... where object_name like 'xxxxx%';

可楼主确实是这样问过的,range index与fast full index scan谁快?
假如返回的结果是相同的,
一个是fast full index scan,一个是index range,由于可以执行fast full index scan,那在index range 中,这个SQL也可以不用访问表而可以直接得到结果,没有跑题吧。


[/B]

两个 like 的差异明显这么大，这种问发，是因为问问题的人不明白，你拿他的 特定情况 下一个  扩大化的的结论
在非常有限条件下成立的东西，放到其他条件下就是错误的结论

若有人引用你的话，不就被你害了?

foreverlee

关于Oracle - Optimising the pattern matching (LIKE '%ABC')
Tom做的回答

http://asktom.oracle.com/pls/ask ... TERIA:5968495479087


没看过的同志还是看看吧

biti_rainy

(LIKE '%ABC')

这是另外一回事,可通过 反向索引来实现

现实就那么几种可能，实际上 index  fast  full  scan 的作用不过相当于是做过小表记录 该字段+rowid 。

也有人对于 like  '%abc%  的处理使用小表来记录
如果恒定的通过某些值来查询的，可以考虑函数索引

如果比较复杂的，还有  oracle  文本索引 也是一种解决方案。


无非都是  利用空间 来换时间，减少不必要的IO。


不论是TOM还是谁来优化，无非都是这几类方案：

在插入的时候增加代价 cpu 和存储 （索引、函数索引（反向索引）、小表）

oracle  text ,定期分析数据的话有延迟，也是利用存储来换时间

所以对于优化如果能站在一个更高一些的角度，编程无非就是在空间和时间之间寻找平衡，当时间要求优先的时候，就看怎么利用空间来替代，从这个角度入手，具体的方法结合oracle的各种特性逐一应用就是了。当然，了解数据库各种特征和功能，是基础。

foreverlee

最初由 biti_rainy 发布
[B](LIKE '%ABC')

这是另外一回事,可通过 反向索引来实现

现实就那么几种可能，实际上 index  fast  full  scan 的作用不过相当于是做过小表记录 该字段+rowid 。

也有人对于 like  '%abc%  的处理使用小表来记录
如果恒定的通过某些值来查询的，可以考虑函数索引

如果比较复杂的，还有  oracle  文本索引 也是一种解决方案。


无非都是  利用空间 来换时间，减少不必要的IO。


不论是TOM还是谁来优化，无非都是这几类方案：

在插入的时候增加代价 cpu 和存储 （索引、函数索引（反向索引）、小表）

oracle  text ,定期分析数据的话有延迟，也是利用存储来换时间

所以对于优化如果能站在一个更高一些的角度，编程无非就是在空间和时间之间寻找平衡，当时间要求优先的时候，就看怎么利用空间来替代，从这个角度入手，具体的方法结合oracle的各种特性逐一应用就是了。当然，了解数据库各种特征和功能，是基础。 [/B]

很中肯的建议。谢谢