EricRay 2013-08-01
最近遇到两个关于Ibatis 转换date类型的问题,记录一下:
sql_text:
select distinct t.cc from aa t
where t.update_time > :1 and t.update_time < :2
Optimizer Plan:
-----------------------------------------------------------------------------------------------------------
| Operation | Name | Rows | Bytes| Cost | Pstart| Pstop |
------------------------------------------------------------------------------------------------------------
| SELECT STATEMENT | | | | 226780 | | |
| HASH UNIQUE | | 5K| 72K| 226780 | | |
| FILTER | | | | | | |
| TABLE ACCESS FULL |AA | 69K| 949K| 226774 | | |
------------------------------------------------------------------------------------------------------------
开始一看以为是没建索引,但是发现索引是存在的,同时explain plan 发现走的也是正确的执行计划。
怀疑是统计信息的问题,于是重新收集了统计信息,并重新生成了执行计划,但是还是同样的。因为那天通宵了一夜,
头脑比较晕,没明白是怎么回事。
回家后仔细看了一下v$sql_plan ,发现如下信息:
(INTERNAL_FUNCTION("S"."UPDATE_TIME")>=:1 AND INTERNAL_FUNCTION("S"."UPDATE_TIME")<:2
表示oracle对这个字段做了转换后再去比较,于是怀疑应用里的类型不对,开发同事提供了如下sql,虽然他传入配置文件的属性是date型。
但是IbatiS并没有转换成oracle能识别的date型:
select distinct t.cc from aa t
where t.update_time > #startTimeStr# and t.update_time < #endTimeStr#
于是通知开发修改语句:
update_time >= to_date(#startTimeStr#,'yyyy-mm-dd hh24:mi:ss') and update_time < to_date(#endTimeStr#,'yyyy-mm-dd hh24:mi:ss')
如:对于sql语句order by #user_id#,如果传入的值是111,那么解析成sql时的值为order by "111", 如果传入的值是id,则解析成的sql为order by "id"。