SQL编写不合理导致历史日志查询特别慢

这是以前的一次SQL查询调优的经历，在这个例子中，由于SQL编写不合理，导致历史日志数据查询特别慢。这个例子的特点，是错误比较隐蔽，初学者很容易犯这种错误。下面就以实际的例子来说明。

当前日期：2015年6月25日。

SQL1：

select count(1)

from t_brm_uw_process_log L

where L.begin_time >= to_date('2014-12-30', 'yyyy-mm-dd')

and L.end_time <= to_date('2014-12-30', 'yyyy-mm-dd') + 1;

结果：5000条记录，执行时间3秒

SQL2：

select count(1)

from t_brm_uw_process_log L

where L.begin_time >= to_date('2015-6-24', 'yyyy-mm-dd')

and L.end_time <= to_date('2015-6-25', 'yyyy-mm-dd') + 1;

结果：30000条记录，执行时间0.2秒

类似的SQL，只是时间范围不一样，begin_time字段上有建索引，为什么SQL2执行更快？

SQL1执行计划：

没有走索引。

SQL2执行计划：

有走索引。

SQL2执行快是因为走了索引，可是SQL1为什么不走索引？

尝试方法1：

针对指定索引重建

ALTER INDEX IDX_BRM_UW_PROCESS_LOG_BG_TIME REBUILD;

无效。

尝试方法2：

是否统计信息不对？需要重建统计信息

直接查询数量，是840万条记录

oracle统计值查看

select DT.NUM_ROWS, --行数

DT.LAST_ANALYZED, --最后分析日期

DT.*

from dba_tables DT

where table_name = 'T_BRM_UW_PROCESS_LOG';

结果：

行数：8379665

最后分析日期：2015/6/23 22:03:44

看起来统计信息也是对的。

失败

最后突然脑子中突然灵光一现，终于发现了问题所在：

SQL写错了！

SQL中两个条件都应该是begin_time为条件,结果第二个条件写成了end_time，导致查询历史日志的时候，根据索引字段begin_time查询出来的数据范围过大，COST太高而不走索引了。

问题原因找到了，改写就很简单了，正确的SQL写法：

select count(1)

from t_brm_uw_process_log L

where L.begin_time >= to_date('2014-12-30', 'yyyy-mm-dd')

and L.begin_time <= to_date('2014-12-30', 'yyyy-mm-dd') + 1;