why? 简单的to_date 函数 怎么会出现这么大的诧异

Question

to_date('20050501','yyyy-mm-dd') 与 to_date('2005-05-01','yyyy-mm-dd') 在 应用中用到， 无意发现 两者查询速度
相差很大 (一个 1s内,一个 30几秒)？ 
不知道这是什么情况！
你们猜哪个是 1s内，哪个是30几秒 再接着往下推测

Answer 1

这还用猜么，无聊啊，to_date('20050501','yyyy-mm-dd')  肯定时间长，ORACLE会进行强制转换

Answer 2

  无聊吧...  ，问题就是  to_date('20050501','yyyy-mm-dd')  在 1 s 内出的结果。
to_date('2005-05-01','yyyy-mm-dd')  30多 s出的结果！！

Answer 3

相反的呀！  本来想上个图证明下的，不能csdn 空间上传个图片还在报 js错 很麻烦！不过事实 还真是和你说的相反的！

Answer 4

to_date('20050501','yyyy-mm-dd')
难道这是标准格式？

Answer 5

SQL> conn scott/tiger
已连接。
SQL> set autotrace on
SQL> set timing on
SQL> select to_date('20120522','yyyy-mm-dd') from dual;TO_DATE('20120
--------------
22-5月 -12已用时间:  00: 00: 00.01执行计划
----------------------------------------------------------
Plan hash value: 1388734953-----------------------------------------------------------------
| Id  | Operation        | Name | Rows  | Cost (%CPU)| Time     |
-----------------------------------------------------------------
|   0 | SELECT STATEMENT |      |     1 |     2   (0)| 00:00:01 |
|   1 |  FAST DUAL       |      |     1 |     2   (0)| 00:00:01 |
-----------------------------------------------------------------
统计信息
----------------------------------------------------------
          1  recursive calls
          0  db block gets
          0  consistent gets
          0  physical reads
          0  redo size
        442  bytes sent via SQL*Net to client
        385  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processedSQL> select to_date('2012-05-22','yyyy-mm-dd') from dual;TO_DATE('2012-
--------------
22-5月 -12已用时间:  00: 00: 00.00执行计划
----------------------------------------------------------
Plan hash value: 1388734953-----------------------------------------------------------------
| Id  | Operation        | Name | Rows  | Cost (%CPU)| Time     |
-----------------------------------------------------------------
|   0 | SELECT STATEMENT |      |     1 |     2   (0)| 00:00:01 |
|   1 |  FAST DUAL       |      |     1 |     2   (0)| 00:00:01 |
-----------------------------------------------------------------
统计信息
----------------------------------------------------------
          1  recursive calls
          0  db block gets
          0  consistent gets
          0  physical reads
          0  redo size
        444  bytes sent via SQL*Net to client
        385  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed
这是执行计划，这两个其实没什么差别。你的30秒？有那么夸张吗？怎么可能达到30秒？这不是oracle的作风！从执行计划可以看出是to_date('2012-05-22','yyyy-mm-dd')比较省时。但这两都是一个数量级的。毫秒级别啊。差异可忽略。

Answer 6

SQL> set timing on;
SQL> select to_date('2012-05-22','yyyy-mm-dd') from dual; 
TO_DATE('2012-05-22','YYYY-MM-
------------------------------
2012-5-22
 
Executed in 0 seconds
 
SQL> select to_date('20120522','yyyy-mm-dd') from dual;
 
TO_DATE('20120522','YYYY-MM-DD
------------------------------
2012-5-22
 
Executed in 0 seconds
 
SQL> 

Answer 7

两个查询sql 其它地方都相同，只有这里的to_date 中间有无横杠的区别，我查询了几次效果都是一样！
而且 现在的 to_date 是用在的 条件列上，而不是查询的数据列上的转换，个人猜测和我的数据多少无吧。
一个表 的记录是 3000w（2.6G）,一个表是300w记录（300M）

Answer 8

嗯，我也觉得有些什么特殊、不确定性的地方.. ，就一个 条件列的 to_date 极小的计算 跟数据的多少并无关系...  可就是有些神奇。

Answer 9

差别一点点效果是这样子的...统计信息
----------------------------------------------------------
          1  recursive calls
          1  db block gets
          0  consistent gets
          0  physical reads
        380  redo size
     184653  bytes sent via SQL*Net to client
       7897  bytes received via SQL*Net from client
        685  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)
      10257  rows processed统计信息
----------------------------------------------------------
          1  recursive calls
          0  db block gets
          0  consistent gets
          0  physical reads
          0  redo size
     184653  bytes sent via SQL*Net to client
       7897  bytes received via SQL*Net from client
        685  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
      10257  rows processed