后端的數(shù)據(jù)持久化使用的是 Mybatis ，在做高并發(fā)下賬戶增減余額的時(shí)候，打算使用樂觀鎖來解決這個(gè)問題。在獲取update操作的返回值時(shí)遇到了一個(gè)問題，似乎 Mybatis 進(jìn)行 update 操作得到的 int 返回值并不是影響的行數(shù)。這下就尷尬了。

一般而言，我們知道當(dāng)我們使用 Mybatis 在 mapper 接口中定義 insert delete 等操作，定義一個(gè) int 類型的返回值，通過該值是否為 0 來判斷數(shù)據(jù)庫中受影響的行數(shù)進(jìn)而判斷操作是否成功。

到底 update 返回值代表什么呢？我們來驗(yàn)證一下便知道了，假設(shè)有如下一張表以及兩條數(shù)據(jù)：

我們來編寫一個(gè)簡單的單元測試用例來驗(yàn)證下,首先使用 mybatis 簡單的寫個(gè) mapper 進(jìn)行更新操作，其中 xml 中的內(nèi)容為：

數(shù)據(jù)庫連接配置為：

接來下，我們來編寫一個(gè)簡單的單元測試來驗(yàn)證下： update 的返回值是不是受影響的記錄的條數(shù) ，對(duì)應(yīng)的單元測試代碼如下：

由單元測試代碼可以得知，我們將要把數(shù)據(jù)庫中兩條記錄的 phone 字段的值由 12345678 修改為 66666666 ,正常情況下， resultCode 將會(huì)返回 2 。因?yàn)?update 操作影響到數(shù)據(jù)庫中這 2 條記錄，這和我們期望 2 是相符合的。那么一切正常的情況下，這次單元測試將會(huì)通過，那么我們運(yùn)行看看結(jié)果：

單元測試通過了，再查看數(shù)據(jù)庫中的記錄：

這說明 mybatis 的 update 更新操作返回值的確是返回受影響的行數(shù)……真的是這樣嗎？

我們知道，當(dāng)數(shù)據(jù)庫中的記錄被修改之后，再次執(zhí)行重復(fù)的 update 操作將不會(huì)影響到新的行數(shù)，為了驗(yàn)證我說的話，我們?cè)囋嚕?/p>

那么，按照這個(gè)邏輯：我們?cè)俅螆?zhí)行這個(gè)單元測試應(yīng)該是， resultCode 返回的應(yīng)該是 0 ，和我們的期望的數(shù)字 2 不一致，將會(huì)導(dǎo)致測試不通過。再次運(yùn)行單元測試：

居然還是 passed ,看到這里聰明的你已經(jīng)看出來了， 默認(rèn)情況下，mybatis 的 update 操作返回值是記錄的 matched 的條數(shù)，并不是影響的記錄條數(shù)。

嚴(yán)格意義上來將，這并不是 mybatis 的返回值，mybatis 僅僅只是返回的數(shù)據(jù)庫連接驅(qū)動(dòng)（通常是 JDBC ）的返回值，也就是說，如果驅(qū)動(dòng)告知更新 2 條記錄受影響，那么我們將得到 mybatis 的返回值就會(huì)是 2 和 mybatis 本身是沒有關(guān)系的。

道理我都懂，如果我們非得要 mybatis 的 update 操作明確的返回受影響的記錄條數(shù)，有沒有什么辦法呢？

當(dāng)然是有的。

通過對(duì) JDBC URL 顯式的指定 useAffectedRows 選項(xiàng)，我們將可以得到受影響的記錄的條數(shù)：

jdbc:mysql://${jdbc.host}/${jdbc.db}?useAffectedRows=true

我們對(duì)我們的數(shù)據(jù)庫連接配置稍做修改，添加 useAffectedRows 字段：

此時(shí)，mybatis 的 update 操作返回的應(yīng)該是受影響的條數(shù)了，我們?cè)俅芜\(yùn)行單元測試試試看：

update 操作返回的是受影響的記錄條數(shù)，我們知道為 0 和我們預(yù)期的 2 不一致，自然而然單元測試不通過咯～。

總結(jié)

以上所述是小編給大家介紹的Mybatis Update操作返回值問題，希望對(duì)大家有所幫助，如果大家有任何疑問請(qǐng)給我留言，小編會(huì)及時(shí)回復(fù)大家的。在此也非常感謝大家對(duì)腳本之家網(wǎng)站的支持！