SQL性能问题求助II

samt007

newkid 发表于 2016-12-1 23:11
在同样的库上，其它索引的操作速度怎么样？
去掉模糊条件后，满足的行数有多少？ORGANIZATION_ID=1108 AND ...

这样子就多了。。。大该45w笔记录。

newkid

samt007 发表于 2016-12-2 07:41
这样子就多了。。。大该45w笔记录。

它必须访问这45W笔记录，然后逐一判断DESCRIPTION LIKE '%员工冬装%'，虽然结果很小，但是工作量很大。

samt007

newkid 发表于 2016-12-2 22:56
它必须访问这45W笔记录，然后逐一判断DESCRIPTION LIKE '%员工冬装%'，虽然结果很小，但是工作量很大。

是这样子的理解。。。唉，oracle在全模糊扫描这块做得真的是不行。
结合实际上使用情况，一般都是全模糊查询描述的较多。

jrtongxin5266

是不是可以考虑建一个联合索引ORGANIZATION_ID与LANGUAGE的，把like那段放最后，会不会快一点呢。

samt007

jrtongxin5266 发表于 2016-12-5 13:07
是不是可以考虑建一个联合索引ORGANIZATION_ID与LANGUAGE的，把like那段放最后，会不会快一点呢。

现在就是这样子建立索引的。
主要的性能还是oracle对全模糊的查询的支持很差啦。

jrtongxin5266

samt007 发表于 2016-12-5 14:38
现在就是这样子建立索引的。
主要的性能还是oracle对全模糊的查询的支持很差啦。

但是我看到你的sql是把like放在中间了，这样的话，你的联合索引还起作用吗？oracle的索引不是从最左侧开始找吗？

samt007

jrtongxin5266 发表于 2016-12-5 16:12
但是我看到你的sql是把like放在中间了，这样的话，你的联合索引还起作用吗？oracle的索引不是从最左侧开 ...

Oracle的执行计划解析器很灵活的。只要栏位足够就肯定会用到组合索引，和调用的顺序无关的。