关于Ibatis 转换 oracle date类型的问题

最新推荐文章于 2021-04-12 23:40:34 发布

原创最新推荐文章于 2021-04-12 23:40:34 发布 · 627 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#数据库

mybatis 专栏收录该内容

12 篇文章

订阅专栏

本文详细记录了解决Ibatis中日期类型转换问题的过程，包括查询SQL语句优化、统计信息收集、以及如何正确使用日期类型进行比较。通过案例分析，探讨了在Ibatis中日期类型转换的问题及解决方案。

最近遇到两个关于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')