MyBatis动态SQL空集合处理方案与线上事故复盘

1. 问题现场还原：一个平静午后的线上事故

那天下午三点二十分，监控系统突然发出刺耳的警报声。我们的核心订单查询接口响应时间从平均50ms飙升到3000ms以上，错误率瞬间突破30%。查看日志发现大量"org.apache.ibatis.binding.BindingException"异常堆栈，伴随着"Parameter '__frch_item_0' not found"的错误信息。

紧急回滚后排查发现，罪魁祸首竟是一段看似无害的MyBatis动态SQL：

xml复制<select id="batchQueryOrders" resultType="Order">
  SELECT * FROM orders 
  WHERE item_id IN
  <foreach collection="itemIds" item="item" open="(" separator="," close=")">
    #{item}
  </foreach>
</select>

当传入的itemIds为空列表时，这段代码没有按我们预期返回空结果，而是直接抛出了BindingException。更糟糕的是，这个异常触发了服务熔断机制，导致整个查询服务不可用。

2. 原理深度剖析：MyBatis foreach的工作机制

2.1 foreach标签的编译过程

MyBatis在处理动态SQL时，会将所有动态标签转换为SqlNode对象。对于foreach标签，会生成一个ForEachSqlNode。关键点在于：

1. 参数绑定机制：MyBatis会为每个迭代元素创建独立的参数名，格式为__frch_item_${index}
2. 空集合处理：当检测到空集合时，默认行为是继续生成SQL片段，而非跳过整个IN条件

2.2 空集合的SQL生成问题

当传入空列表时，生成的SQL会变成：

sql复制SELECT * FROM orders WHERE item_id IN ()

这在大多数数据库（MySQL、Oracle等）中都是非法语法。但问题在于，MyBatis并没有在SQL生成阶段检查这种无效情况。

2.3 参数绑定的时序问题

异常信息中的__frch_item_0揭