奇怪的问题

in SQPLUS : set autotrace on

then input your sql and see the explain plan returned by oracle :-)

符合a3 between to_date('2001-08-02','yyyy-mm-dd') and to_date('2001-08-02','yyyy-mm-dd')条件的数据特别多吗？

我做了一个测试两个表
test1(id number(10),name varchar(100),ptime date)
test1(id number(10),name varchar(100),ptime varchar2(10))
都有10万条纪录，
select count(*) from test1
where ptime between to_date('2000/08/02','yyyy/mm/dd')
and to_date('2003/08/02','yyyy/mm/dd')
order by ptime Elapsed: 00:00:00.31 select count(*) from test2
where to_date(ptime,'yyyy/mm/dd') between to_date('2000/08/02','yyyy/mm/dd')
and to_date('2003/08/02','yyyy/mm/dd')
order by ptime Elapsed: 00:00:02.24
查询结果相同，时间不同
怎么和你的结果不同啊

sql>set autotrace on
无法验证 plan table 格式或实体
启用explain报告时出错
无法找到会话表示府。启用检查PLUSTRACE角色
启用STATISTICE报告时出错

如果a3有索引，你试试这个语句，看看速度怎么样
select * from tb1
where a1 like '%ddd%'
and a3>=to_date('2001-08-02','yyyy-mm-dd')
and a3<=to_date('2001-08-02','yyyy-mm-dd')
order by a3
------------
注意：a1 like '%ddd%'要放在前面。还有，我觉得这么写比between好

在我所经历中，
and a3>=……
and a3<=……
这种写法有索引的时候和between速度差不多
但没有索引的时候，比between的速度要快。
还有，日期型检索肯定比vrachar2快。你是建的一样的索引吗？

我知道原因了
第一次执行慢是因为like ，他是对全表搜索，当然慢
第二次快是因为同样的like刚执行完，当然比第一次快
如果你去掉like 条件，结果就不一样了

在执行set autotrace on 或 explain plan命令前，先执行如下命令：
SQL>@ D:\Oracle\Ora81\RDBMS\ADMIN\utlxplan.sql (路径要改)

不仅仅是索引的问题
你使用了like，这必然导致全表搜索
第一次执行当然就慢了，第二次已经搜索过了，自然就比第一次快了
这次是正确的解释了，把奖励分数给我

"使用了like，这必然导致全表搜索"成立吗？
第一种方案应该利用上了索引，第二种方案肯定没用上索引。速度应该是第一种快呀－－好好奇怪！

根本就不奇怪
date类型的条件查询比 varchar2的快，
如果把like 的条件去掉，就是正常的了
你使用了like，这必然导致全表搜索
第一次执行当然就慢了，第二次已经搜索过了，自然就比第一次快了
这次是正确的解释了，把奖励分数给我，否则下次不管你了

也许是这样的：你的数据中a2的值并不是单调增或减（值不很集中），或是分布很不均匀，在这种情况下，如果要读取的记录也比较多，用索引反而比直接表扫描慢，因为不能预读，逻辑IO太大。而你的第一个语句是能够用索引的，第二个语句因为是to_date(a2,'yyyy-mm-dd')就用不了索引。

1.先测字符型的，再测日期型的试试
2.把like去掉试试结果贴出来，大家看看

解决方案 »