发现mybatisplus#Wrapper的一个小坑
什么坑?看如下demo代码:
public void getOne() {
LambdaQueryWrapper <SbhPlatOrder> wrappers = new LambdaQueryWrapper<> ();
wrappers.eq(SbhPlatOrder::getOrderId, 1L );
sbhPlatOrderManager.getOne(wrappers);
}
这里要说的是 eq 方法。该方法在mybatis-plus-core包里的Compare.java接口里,这个 eq 重载的方法签名如下:
// 在com.baomidou.mybatisplus.core.conditions.interfaces.Compare.java里 default Children eq(R column, Object val) { return eq( true , column, val);
}
注意到这个 eq 方法的第二个参数的类型是 Object。
上面demo代码中,SbhPlatOrder#orderId 是String类型, 对应数据库里的字段的类型是 varchar。 而demo里给的参数值是个Long型数字。
这种情况下, mybatisplus——严格说,应该是mybatis——生成的sql日志如下,也就是说,sql语句是: SELECT * FROM sbh_plat_order WHERE order_id = 1
16:40:44.287 DEBUG SbhPlatOrderMapper.selectOne:143 :==> Preparing: SELECT * FROM sbh_plat_order WHERE order_id = ? 16:40:44.336 DEBUG SbhPlatOrderMapper.selectOne:143 :==> Parameters: 1(Long)
but,但是,however,我们期望的SQL语句是: SELECT * FROM sbh_plat_order_20221026 WHERE order_id = ' 1 '
我的mybatisplus版本是 com.baomidou:mybatis-plus-boot-starter:jar:3.1.2, 希望高版本的mybatisplus可以解决这个类型转换问题。
之所以提这个坑,是因为,今天下午,通过监控系统,发现我们系统生产能力突然下降,频繁报无法获取数据库连接。
最终排查出来的原因,竟然是因为mybatisplus的这个“坑”导致的。 数据表 levy_payment_flow 的字段flow_no前不久 由 bigint 改成了 varchar ( 32 ) 。而程序里依然存在 wrappers.eq(SbhPlatOrder::getFlowNo, Long.parseLong(requestNo)); 这样的代码。赶上今天系统交易量大,就曝出问题了。 levy_payment_flow 的字段flow_no 有唯一索引, 而 SELECT * FROM levy_payment_flow WHERE flow_no = 1642499617556336 因为类型不匹配,是不会命中这个唯一索引的,导致全表扫描, SELECT * FROM levy_payment_flow WHERE flow_no = ' 1642499617556336 ' 才会。结果呢,问题sql执行耗时长达30s,修正程序改为后者那个SQL后,就是毫秒级了。