看到论坛中一个帖子：http://www.itpub.net/326343.html
两个sql语句的执行计划完全相同，但是执行花费的时间相差了近一倍。于是打算借这个问题说说如何处理常量可以使sql运行的更快。
当CBO发现表达式中存在常量或常量表达式时，优化器会在SQL执行之前将表达式的值计算出来，避免在表达式中进行多次计算。但是优化器无法将等号（不等号、大于号、小于号等）一边的常量移动到等式的另一边。
举例说明：
COL = 1000
COL = 500 + 500
COL – 500 = 500
虽然上面的三个等式是等价的，但是CBO只能将第二个转化为第一个等式，而第三个优化器是没有办法优化的。
第三个等式由于对列包含了运算，因此不能使用这个列的索引（当然可以使用函数索引）。不考虑索引的因素，假设COL列上没有索引，都执行全表扫描操作，第三种方式仍然是最费时的。对于全表扫描，Oracle会根据等式的条件对表中每条记录进行过滤，对于1、2来说，这里只是一个比较的过程。而对于3来说，对于Oracle每条记录都要执行一个“-500”的操作，然后在与500比较，当数据量大的时候，必然会造成一定性能问题。论坛中那个帖子中遇到的就是这个问题。
下面看一个经过简化的例子：
首先构造一个居然一定数据量的表。
SQL> create table t as select * from dba_objects;
表已创建。
SQL> insert into t select * from t;
已创建6273行。
SQL> insert into t select * from t;
已创建12546行。
SQL> insert into t select * from t;
已创建25092行。
SQL> insert into t select * from t;
已创建50184行。
SQL> insert into t select * from t;
已创建100368行。
SQL> insert into t select * from t;
已创建200736行。
SQL> commit;
提交完成。
SQL> select count(*) from t;
COUNT(*)
----------
401472
然后寻找包含较多数据的一天用于测试。
SQL> select trunc(created), count(*) from t group by trunc(created)
2 having count(*) > 10000;
TRUNC(CREATED) COUNT(*)
------------------- ----------
2004-06-29 00:00:00 358144
2004-11-15 00:00:00 34304
下面包括4条sql语句，这4条sql语句完全是等价的。执行计划也没有其它的选择，只能是全表扫描，来测试一下它们所需的执行时间。
为了避免数据缓存带来的误差，每个sql执行两次，取第二次执行时间。
语句一：推荐写法
SQL> set timing on
SQL> select count(*)
2 from t
3 where created >= to_date('2004-06-29 00:00:00', 'yyyy-mm-dd hh24:mi:ss')
4 and created < to_date('2004-06-30 00:00:00', 'yyyy-mm-dd hh24:mi:ss')
5 group by owner;
COUNT(*)
----------
448
99968
223872
25472
8384
已用时间: 00: 00: 00.08
SQL> select count(*)
2 from t
3 where created >= to_date('2004-06-29 00:00:00', 'yyyy-mm-dd hh24:mi:ss')
4 and created < to_date('2004-06-30 00:00:00', 'yyyy-mm-dd hh24:mi:ss')
5 group by owner;
COUNT(*)
----------
448
99968
223872
25472
8384
已用时间: 00: 00: 00.07
语句二：如果不能避免常量的计算或类型转化，尽量让计算或转化的结果直接等于列的值，不要对列进行计算或转化。
SQL> select count(*)
2 from t
3 where created >= to_date(to_char(to_date('2004-06-29 00:00:00', 'yyyy-mm-dd hh24:mi:ss') - 123.456, 'yyyy-mm-dd hh24:mi:ss'), 'yyyy-mm-dd hh24:mi:ss') + 123.456
4 and created < to_date(to_char(to_date('2004-06-30 00:00:00', 'yyyy-mm-dd hh24:mi:ss') + 1000, 'yyyy-mm-dd hh24:mi:ss'), 'yyyy-mm-dd hh24:mi:ss') - 1000
5 group by owner;
COUNT(*)
----------
448
99968
223872
25472
8384
已用时间: 00: 00: 00.09
SQL> select count(*)
2 from t
3 where created >= to_date(to_char(to_date('2004-06-29 00:00:00', 'yyyy-mm-dd hh24:mi:ss') - 123.456, 'yyyy-mm-dd hh24:mi:ss'), 'yyyy-mm-dd hh24:mi:ss') + 123.456
4 and created < to_date(to_char(to_date('2004-06-30 00:00:00', 'yyyy-mm-dd hh24:mi:ss') + 1000, 'yyyy-mm-dd hh24:mi:ss'), 'yyyy-mm-dd hh24:mi:ss') - 1000
5 group by owner;
COUNT(*)
----------
448
99968
223872
25472
8384
已用时间: 00: 00: 00.08
即使包含了比较复杂的运算和多次数据转化，但是常量在执行开始之间就计算好了，因此，一次的计算不会对查询带来多大的影响。
语句三：
SQL> select count(*)
2 from t
3 where to_char(created, 'yyyy-mm-dd') = '2004-06-29'
4 group by owner;
COUNT(*)
----------
448
99968
223872
25472
8384
已用时间: 00: 00: 01.02
SQL> select count(*)
2 from t
3 where to_char(created, 'yyyy-mm-dd') = '2004-06-29'
4 group by owner;
COUNT(*)
----------
448
99968
223872
25472
8384
已用时间: 00: 00: 01.03
由于对于每条记录都要对CREATED列进行类型转化，因此会耗费相当多的执行时间。
语句四：
SQL> select count(*)
2 from t
3 where to_char(created, 'yyyy-mm-dd hh24:mi:ss') >= '2004-06-29 00:00:00'
4 and to_char(created, 'yyyy-mm-dd hh24:mi:ss') <= '2004-06-29 23:59:59'
5 group by owner;
COUNT(*)
----------
448
99968
223872
25472
8384
已用时间: 00: 00: 02.02
SQL> select count(*)
2 from t
3 where to_char(created, 'yyyy-mm-dd hh24:mi:ss') >= '2004-06-29 00:00:00'
4 and to_char(created, 'yyyy-mm-dd hh24:mi:ss') <= '2004-06-29 23:59:59'
5 group by owner;
COUNT(*)
----------
448
99968
223872
25472
8384
已用时间: 00: 00: 02.04
由于包含了两次条件语句，对于每条记录需要对CREATED列进行两次转化，因此所需时间是语句三的二倍。
因此，在写sql时，应该尽量避免对列操作，这样不仅会导致无法使用索引，而且还会增加执行成本，导致sql执行速度变慢。
当前位置：
论坛首页 »
自由讨论区 »
MySQL, Oracle及数据库讨论区
»
发起投票
技术讨论
加好友
发消息
2011-8-11 10:04:28 |
赞(
操作
