發現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(no)); 這樣的代碼，

趕上今天系統交易量大，就曝出問題了， 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后，就是毫秒級了，

當看到一些不好的代碼時，會發現我還算優秀；當看到優秀的代碼時，也才意識到持續學習的重要！--buguge
本文來自博客園，轉載請注明原文鏈接：https://www.cnblogs.com/buguge/p/16830176.html

轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/520618.html

標籤：其他

上一篇：C語言之圍棋（利用佇列實作）

下一篇：Mybatis常見知識點