mybatisplus的坑 insert標簽insert into select無參數問題的解決
mybatisplus的坑 insert標簽insert into select無參數
實際項目中發現
<insert id="xxx"> insert into xxxx select xxxx </insert>
會報錯
org.mybatis.spring.MyBatisSystemException: nested exception is org.apache.ibatis.exceptions.PersistenceException:
### Error updating database. Cause: java.lang.NullPointerException
### Cause: java.lang.NullPointerException
at org.mybatis.spring.MyBatisExceptionTranslator.translateExceptionIfPossible(MyBatisExceptionTranslator.java:77)
幾經排查
com.baomidou.mybatisplus.processBatch方法 TableInfo tableInfo = TableInfoHelper.getTableInfo(parameterObject.getClass());
這裡會取參數對象作為表信息,由於沒傳參數,所以報錯
改用<update>標簽,問題解決~
insert into select語句的坑
Insert into select請慎用。這天xxx接到一個需求,需要將表A的數據遷移到表B中去做一個備份。本想通過程序先查詢查出來然後批量插入。但xxx覺得這樣有點慢,需要耗費大量的網絡I/O,決定采取別的方法進行實現。通過在Baidu的海洋裡遨遊,他發現瞭可以使用insert into select實現,這樣就可以避免使用網絡I/O,直接使用SQL依靠數據庫I/O完成,這樣簡直不要太棒瞭。然後他就被開除瞭。
事故發生的經過
由於數據數據庫中order_today數據量過大,當時好像有700W瞭並且每天在以30W的速度增加。所以上司命令xxx將order_today內的部分數據遷移到order_record中,並將order_today中的數據刪除。這樣來降低order_today表中的數據量。由於考慮到會占用數據庫I/O,為瞭不影響業務,計劃是9:00以後開始遷移,但是xxx在8:00的時候,嘗試遷移瞭少部分數據(1000條),覺得沒啥問題,就開始考慮大批量遷移。
- 在遷移的過程中,應急群是先反應有小部分用戶出現支付失敗,隨後反應大批用戶出現支付失敗的情況,以及初始化訂單失敗的情況,同時騰訊也開始報警。
- 然後xxx就慌瞭,立即停止瞭遷移。
本以為停止遷移就就可以恢復瞭,但是並沒有。後面發生的你們可以腦補一下。
事故還原
在本地建立一個精簡版的數據庫,並生成瞭100w的數據。模擬線上發生的情況。
建立表結構
訂單表
CREATE TABLE `order_today` ( `id` varchar(32) NOT NULL COMMENT '主鍵', `merchant_id` varchar(32) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL COMMENT '商戶編號', `amount` decimal(15,2) NOT NULL COMMENT '訂單金額', `pay_success_time` datetime NOT NULL COMMENT '支付成功時間', `order_status` varchar(10) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL COMMENT '支付狀態 S:支付成功、F:訂單支付失敗', `remark` varchar(100) CHARACTER SET utf8 COLLATE utf8_general_ci DEFAULT NULL COMMENT '備註', `create_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '創建時間', `update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '修改時間 -- 修改時自動更新', PRIMARY KEY (`id`) USING BTREE, KEY `idx_merchant_id` (`merchant_id`) USING BTREE COMMENT '商戶編號' ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
訂單記錄表
CREATE TABLE order_record like order_today;
模擬遷移
把8號之前的數據都遷移到order_record表中去。
INSERT INTO order_record SELECT * FROM order_today WHERE pay_success_time < '2020-03-08 00:00:00';
在navicat中運行遷移的sql,同時開另個一個窗口插入數據,模擬下單。
從上面可以發現一開始能正常插入,但是後面突然就卡住瞭,並且耗費瞭23s才成功,然後才能繼續插入。這個時候已經遷移成功瞭,所以能正常插入瞭。
出現的原因
在默認的事務隔離級別下:insert into order_record select * from order_today 加鎖規則是:order_record表鎖,order_today逐步鎖(掃描一個鎖一個)分析執行過程。
通過觀察遷移sql的執行情況你會發現order_today是全表掃描,也就意味著在執行insert into select from 語句時,mysql會從上到下掃描order_today內的記錄並且加鎖,這樣一來不就和直接鎖表是一樣瞭。
這也就可以解釋,為什麼一開始隻有少量用戶出現支付失敗,後續大量用戶出現支付失敗,初始化訂單失敗等情況,因為一開始隻鎖定瞭少部分數據,沒有被鎖定的數據還是可以正常被修改為正常狀態。由於鎖定的數據越來越多,就導致出現瞭大量支付失敗。最後全部鎖住,導致無法插入訂單,而出現初始化訂單失敗。
解決方案
由於查詢條件會導致order_today全表掃描,什麼能避免全表掃描呢,很簡單嘛,給pay_success_time字段添加一個idx_pay_suc_time索引就可以瞭,由於走索引查詢,就不會出現掃描全表的情況而鎖表瞭,隻會鎖定符合條件的記錄。
最終的sql
INSERT INTO order_record SELECT * FROM order_today FORCE INDEX (idx_pay_suc_time) WHERE pay_success_time <= '2020-03-08 00:00:00';
執行過程
小結一下
使用insert into tablA select * from tableB語句時,一定要確保tableB後面的where,order或者其他條件,都需要有對應的索引,來避免出現tableB全部記錄被鎖定的情況。
以上為個人經驗,希望能給大傢一個參考,也希望大傢多多支持WalkonNet。
推薦閱讀:
- MySQL 超大表快速刪除方式
- mysql主鍵id的生成方式(自增、唯一不規則)
- 利用Mysql定時+存儲過程創建臨時表統計數據的過程
- 詳細談談MYSQL中的COLLATE是什麼
- sql查詢語句之平均分、最高最低分及排序語句