快捷導(dǎo)航

MyBatis 的一級緩存導(dǎo)致的數(shù)據(jù)一致性問題分析及解決方法

更新時間：2025年06月24日 10:49:44 作者：小時候的陽光

在MySQL提交讀隔離級別下,MyBatis一級緩存導(dǎo)致同一SqlSession內(nèi)重復(fù)查詢結(jié)果不更新,即使數(shù)據(jù)庫已變更,下面給大家介紹MyBatis 的一級緩存導(dǎo)致的數(shù)據(jù)一致性問題分析及解決方法,感興趣的朋友一起看看吧

問題說明

下面一段示例的業(yè)務(wù)邏輯代碼：

@Transactional(propagation = Propagation.REQUIRED, rollbackFor = Exception.class)
@Override
public void flushOrderDetail(FlushForm form) {
    // 構(gòu)建批量更新訂單狀態(tài)的參數(shù)集合
    List<FlushOrderParam> flushOrderParamList = payService.createFlushParam(form);
    // 查詢出本次需要更新的訂單記錄
    List<OrderEntity> orderList = orderService.query(form);
    SqlSession sqlSession = null;
    try {
        // 采用MyBatis批處理模式，開啟批量執(zhí)行的SqlSession
        sqlSession = sqlSessionFactory.openSession(ExecutorType.BATCH);
        // 批量處理訂單狀態(tài)信息
        orderService.batchUpdate(sqlSession, flushOrderParamList, orderList);
        // 提交批量處理事務(wù)
        sqlSession.commit();
    } catch (Exception e) {
        // 出現(xiàn)異常時，回滾批處理操作
        log.error("批處理訂單狀態(tài)失敗", e);
        if (sqlSession != null) sqlSession.rollback();
        // 將異常拋出，觸發(fā)Spring事務(wù)管理的回滾機制
        throw e;
    } finally {
        // 關(guān)閉SqlSession，釋放資源
        if (sqlSession != null) {
            try {
                sqlSession.close();
            } catch (Exception e) {
                log.error("關(guān)閉sqlSession異常", e);
            }
        }
    }
    // 批量操作成功后，再次查詢訂單，打印訂單狀態(tài)日志，便于排查和驗證
    orderList = orderService.query(form);
    for (OrderEntity order : orderList) {
        logger.debug("訂單 {} 狀態(tài) {}", order.getOrderCode(), order.getStatus());
    }
}

上面這段Spring業(yè)務(wù)代碼主要內(nèi)容就是想根據(jù)參數(shù)批量更新訂單狀態(tài)，里面使用了Spring的事務(wù)注解，同時方法中另外開啟了一個數(shù)據(jù)庫會話用于批處理更新，這樣可以加快速度。

這段代碼連接的數(shù)據(jù)庫是 MySQL, 且事務(wù)隔離級別為 提交讀（READ-COMMITTED），查詢MySQL事務(wù)隔離方法如下：

SELECT @@session.transaction_isolation;

問題現(xiàn)象：
orderList = orderService.query(form); 查詢出來的訂單狀態(tài)沒有變化，但是數(shù)據(jù)庫中已經(jīng)更新 !

問題原因

并非AI 給出的回答：因為兩個不同的事務(wù)管理器導(dǎo)致不一樣的結(jié)果…

首先，在提交讀的隔離級別下，即便不同的事務(wù)管理器也可以相互讀取到對方數(shù)據(jù)庫會話已經(jīng)提交的事務(wù)數(shù)據(jù)

那為什么讀取到的最后狀態(tài)沒有變化？ 因為 MyBatis 一級緩存導(dǎo)致

MyBatis 一級緩存默認綁定在一個 SqlSession 的生命周期內(nèi)下，
上面代碼中的開頭和結(jié)尾的 orderService.query(form) 是在同一個SqlSession生命周期下
且查詢參數(shù)一樣，這樣導(dǎo)致兩次查詢結(jié)果一樣，但數(shù)據(jù)庫中其實已經(jīng)狀態(tài)更新了

問題解決

修改一級緩存的隔離級別為 ·statement· 級別，這樣等同于關(guān)閉一級緩存。

mybatis:
  type-aliases-package: com.middol.*.model.**.dao
  mapper-locations: classpath:mapper/**/*Mapper.xml
  configuration:
    map-underscore-to-camel-case: true # 開啟駝峰功能
    local-cache-scope: statement

主要關(guān)注 local-cache-scope: statement

或者上面代碼放棄使用批處理模式，采用同一個SqlSession下操作數(shù)據(jù)庫，
或者直接使用批處理的SqlSession查詢訂單表。

到此，問題原因和處理說明完畢！

到此這篇關(guān)于MyBatis 的一級緩存導(dǎo)致的數(shù)據(jù)一致性問題分析的文章就介紹到這了,更多相關(guān)MyBatis一級緩存導(dǎo)致數(shù)據(jù)一致性內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

您可能感興趣的文章: