视图内查询和试图外查询效率问题

[不断学习的ITer]

有个视图，几张表通过 union all 组合。

第一：如果将日期的查询条件写在试图外，效率很慢。如果不用视图，将查询条件放在每个表的后面，后面就很快。求解释。
第二：在视图后面有个筛选条件，根据表中的一个非主键字段：varchar2（4）进行筛选。结果加上trim的速度很快，不加速度很慢。求解释。

[bw555]

1、举个例子，两种方案，看看那个快 a、有10个班，每班100人，从每个班找成绩过90的 b、把10个班的人都集合到操场上，从1000个人中挑成绩过90的，那个快？

[bw555]

二，由于是非主键字段，应该也没建索引吧，索引trim前后都不会使用索引 trim之后，长度变短了，字符串本身是逐个字符比较的，比较起来肯定会变快的啊

[小灰狼W]

通过union连接以后，外层的条件不能作用到内层，导致先获取视图的结果集，再筛选，资源存在浪费 第二点没怎么看明白，where a=xxx慢，用where trim(a)=xxx 就变快了？ 不会是建了trim()的函数索引吧，看下执行计划

[不断学习的ITer]

引用 1 楼 bw555 的回复:

1、举个例子，两种方案，看看那个快 a、有10个班，每班100人，从每个班找成绩过90的 b、把10个班的人都集合到操场上，从1000个人中挑成绩过90的，那个快？

有个问题：在这种多表union条件下，是不是最好不要用视图？

[bw555]

引用 4 楼 wyqlxy 的回复:

有个问题：在这种多表union条件下，是不是最好不要用视图？

建视图的目的一般情况下是减少应用程序上面的复杂度，再不太影响效率的情况下，用视图还是不错的

[ning_wnn2014]

引用 2 楼 bw555 的回复:

二，由于是非主键字段，应该也没建索引吧，索引trim前后都不会使用索引 trim之后，长度变短了，字符串本身是逐个字符比较的，比较起来肯定会变快的啊

学习了

[riskyvall]

第一个很显然是union all 并多个表 没有日期条件 数据量大 没有过滤 当然慢 第二个 trim把这个字段的空值过滤了