mybatis查询日期范围速度慢的原因

[下一行code]

mybatis代码如下：

SELECT * FROM server_log s WHERE
		 (s.createTime >= to_date(#{startTime},'yyyy-MM-DD') and s.createTime <= to_date(#{endTime} ,'YYYY-MM-DD')) 
		AND
			appSerialNumber=#{appNum}
		ORDER BY #{attribute}

控制台输出
14:24:53,527 DEBUG PreparedStatement:27 - ==> Executing: SELECT * FROM server_log s WHERE (s.createTime >= to_date(?,'yyyy-MM-DD') and s.createTime <= to_date(? ,'YYYY-MM-DD')) AND appSerialNumber=? ORDER BY ?
14:24:53,528 DEBUG PreparedStatement:27 - ==> Parameters: 2014-07-02(String), 2014-08-01(String), 0002(String), createTime(String)
在执行这个查询的时候特别慢，用秒表粗略计算了下，大约需要160多秒，然后将控制台SQL语句复制到sqldeveloper中手动补全参数后执行，几乎不到3秒就出结果了，在sqldeveloper中执行的SQL语句如下
SELECT * FROM server_log s WHERE (s.createTime >= to_date('2014-07-02','yyyy-MM-DD') and s.createTime <= to_date('2014-08-01' ,'YYYY-MM-DD')) AND appSerialNumber='0002' ORDER BY createTime;

为什么这个语句在mybatis执行的时候会如此的慢，而用sqldeveloper执行却可以这么快的出结果？

没有积分了，后面我再补上！！！

[shixitong]

确定是程序执行这条sql语句要160多秒，不是其它原因？

[下一行code]

引用 1 楼 shixitong 的回复:

确定是程序执行这条sql语句要160多秒，不是其它原因？

确定！因为日志输出是这样的 14:48:12,101 DEBUG PreparedStatement:27 - ==> Executing: SELECT * FROM server_log s WHERE (s.createTime >= to_date(?,'yyyy-MM-DD') and s.createTime <= to_date(? ,'YYYY-MM-DD')) AND appSerialNumber=? ORDER BY ? 14:48:12,101 DEBUG PreparedStatement:27 - ==> Executing: SELECT * FROM server_log s WHERE (s.createTime >= to_date(?,'yyyy-MM-DD') and s.createTime <= to_date(? ,'YYYY-MM-DD')) AND appSerialNumber=? ORDER BY ? 14:48:12,101 DEBUG PreparedStatement:27 - ==> Parameters: 2014-07-02(String), 2014-08-01(String), 0002(String), createTime(String) 14:48:12,101 DEBUG PreparedStatement:27 - ==> Parameters: 2014-07-02(String), 2014-08-01(String), 0002(String), createTime(String) 然后160多秒后出现 14:50:43,439 DEBUG Connection:27 - xxx Connection Closed 用断点也跟过了，就是在session.selectList()这行等了160多秒.......

[shixitong]

不太清楚 http://www.myexception.cn/sql/897236.html 看看这篇文章能不能帮到你

[下一行code]

引用 3 楼 shixitong 的回复:

不太清楚 http://www.myexception.cn/sql/897236.html 看看这篇文章能不能帮到你

按照你说的改动了下，还是很慢，控制台输出结果： 15:11:03,853 DEBUG Connection:27 - ooo Connection Opened 15:11:03,890 DEBUG PreparedStatement:27 - ==> Executing: SELECT * FROM server_log s WHERE (s.createTime >= to_date('2014-07-02 00:00:00','yyyy-mm-dd hh24:mi:ss') and s.createTime <= to_date('2014-08-01 23:59:59' ,'yyyy-mm-dd hh24:mi:ss')) AND appSerialNumber=0002 ORDER BY createTime 15:11:03,890 DEBUG PreparedStatement:27 - ==> Executing: SELECT * FROM server_log s WHERE (s.createTime >= to_date('2014-07-02 00:00:00','yyyy-mm-dd hh24:mi:ss') and s.createTime <= to_date('2014-08-01 23:59:59' ,'yyyy-mm-dd hh24:mi:ss')) AND appSerialNumber=0002 ORDER BY createTime 15:11:03,891 DEBUG PreparedStatement:27 - ==> Parameters: 15:11:03,891 DEBUG PreparedStatement:27 - ==> Parameters: 15:13:37,193 DEBUG Connection:27 - xxx Connection Closed

[showhunter74]

直接把sql贴到数据库里直接跑，看看耗时。这160秒不太可能是查询时间

[下一行code]

引用 5 楼 showhunter74 的回复:

直接把sql贴到数据库里直接跑，看看耗时。这160秒不太可能是查询时间

贴到sqldeveloper里跑，不到3秒就出结果了！！！

[骑士的崛起]

肯定是哪里搞错，好好检查下，把mybatis里的sql改成select 1 from dual试试，时间差距这么大肯定不是什么效率问题。

[S117]

又没有加索引什么的呀，哪那条语句拿出来，加上explain看下执行计划

[下一行code]

引用 7 楼 zxcvbnm11920 的回复:

肯定是哪里搞错，好好检查下，把mybatis里的sql改成select 1 from dual试试，时间差距这么大肯定不是什么效率问题。

其他语句执行都正常，就只有我贴出来的这个语句执行超级慢！！

[致知Fighting]

返回的结果太多，取数据的时候花的时间太多了吧 在数据库里查出来多少数据？3秒我估计有不少数据了

[猿敲月下码]

尝试不用to_date()函数 把日期参数String改成Date类型试试

[attilax]

to_date(#{startTime},'yyyy-MM-DD') 这样的函数根本就使用不到索引..当然慢的拉... 要使用 >= 或者<=的方法才行.... 可以参考 paip.取当天记录的方法sql跟hql hibernate

[suciver]

楼主这种情况应该是出在mybatis对你这个sql的解析上浪费了太多时间，毕竟你这个sql放到数据库去查很快，而mybatis却很慢，说明不是这个sql的问题而是你写在mybatis xml文件里面的问题。我看楼主这个sql写在xml里用了>=和<=不要这么用。你用 <![CDATA[]]>把你的sql包起来里面直接用<=和>=试试

[ajfajz]

请问最后是怎么解决的？

[ylovep]

单纯的查询？不需要映射？

[Java_Li_peng]

我现在也遇到了楼主这样的问题，请问最后是怎么解决的，楼主说一下吧。。

[智行天下8]

我估计是返回的数据记录太多导致的，sqldeveloper默认返回前面一些数据，而你用mybatis返回了所有记录，你用sqldeveloper往后拖，返回所有记录肯定也会很慢的。 核心问题就在用了to_date函数后，导致不能走索引了。 解决方法是不用函数，或者建立一个函数索引，或者返回部分数据。

[Vincent_Xu的博客]

去掉to_date 函数 换成String，把 and 换成 between试试，尝试先把 order by time换成其他字段或者去掉看看。 了解Mybatis 编译sql 的一些原理吧。客户端查询3秒，后台要160秒，不太可能，数据量有多大。

[忆赋]

怀疑是你的数据太多导致的。 正确做法是 把 # 换成 $（这个时候先不考虑防注入了），当然了，参数也要加上 ''。 因为#的时候是预编译（相当于 pre.setString(1,"aaa"），出于防注入的考虑），$的时候是sql的字符串拼接（也就相当于你把sql直接复制过去执行）