【问题标题】:Foreach in Mybatis is hard parse or soft parse?Mybatis中的foreach是硬解析还是软解析?
【发布时间】:2014-03-16 19:43:24
【问题描述】:

我正在尝试在 MyBatis-3.2 中制定动态查询。该查询涉及传递项目列表的“IN”子句。 MyBatis 确实通过 foreach 构造支持 'IN' 子句。 该查询将非常频繁地用于可变大小的项目列表。 另外,我不希望 oracle 每次都硬解析这个 sql 查询。

所以,这是我的担忧 -

1) MyBatis中的Foreach是硬解析还是软解析?

2) 如果是软解析,IN子句列表的值什么时候替换?

3) 如果很难解析,是否有解决方法来支持这个用例?在这种情况下,我们可以将列表绑定到一个变量以支持软解析吗?

我在网上搜索了所有这些问题,但找不到任何运气。 对此的任何 cmets 都会有很大帮助。 :)

提前致谢,

【问题讨论】:

    标签: java database oracle mybatis dynamic-sql


    【解决方案1】:

    据我所知,MyBatis 会在将 SQL 发送到数据库进行处理之前替换您的 foreach。它首先替换您提供的所有参数并处理所有 foreach、if 等标签,然后将完整的 SQL 发送到数据库

    【讨论】:

      【解决方案2】:

      首先,在投入大量精力之前,请确保解析确实是一个瓶颈。网络往返和磁盘访问通常会增加查询执行时间。

      因此,您需要做的第一件事就是通过衡量来衡量和指导您的工作,以避免过早优化。

      将 mybatis 中的 foreach 视为构造查询字符串的一种方式(您也可以在 java 中进行更详细的操作),然后将其提交到数据库执行。 软/硬解析仅在数据库中的查询处理期间才有意义,因此 mybatis 与此无关。

      有一些方法可以克服关于 IN 子句的 SQL 限制。首先遵循一些简化解析和/或重用已解析语句的一般准则:

      1. 如果可能,根本不要使用 IN。想想 IN 的参数来自哪里。它们是由于某些查询而出现的吗?能否合并两个查询而不将列表传递给 IN?
      2. 使用简单查询。如果查询很简单,解析的“困难”阶段也将花费更少的时间。

      您也可以尝试创建takes arrayreturns result set 的存储过程。 这肯定会允许您重用已解析的查询,但会增加一些复杂性和潜在的查询处理开销,如果有意义则需要测量。

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 2011-03-04
        • 1970-01-01
        • 2012-06-23
        • 2016-04-04
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多