有這樣一段業務邏輯，首先保存業務數據，然后發送報文，最后確認報文回來以后更新業務數據。偽代碼大概是這樣的：

/**
 * 保存數據，并調用發送報文方法
 */
public void save() {
    // 0.保存數據
    // 調用send()方法
    send();
}

/**
 * 發送報文
 */
public void send() {
    //  1.發送報文（調用Dubbo服務）
    
    //  2.更新數據狀態
}

/**
 * 回調
 */
public void callback() {
    //  3.收到確認報文
    
    //  4.查詢業務數據，并更新數據狀態
}

然而，出問題了。。。

在回調方法中，根據業務單號查詢業務單數據時查不到。這剛插入的數據，怎么就查不到呢？

首先排除了MyBatis-Plus的問題，因為代碼寫法肯定是沒有問題的，然后我想有可能是確認報文回來太快了，導致查詢的時候插入還沒完成，但是細想之下又覺得不太對，在發送報文之前數據已經保存成功了。于是，問題變成了數據保存成功，但是查不到，應該是事務的問題，即保存成功了，但是還沒提交，而隔離級別又是“可重復讀”，所以在回調處理的時候查不到未提交的數據。但是我沒有加事務。

帶著疑問，我查看了bin-log日志，這里需要用到mysqlbinlog命令

mysqlbinlog --help

mysqlbinlog --database=draft_cust --start-datetime="2024-01-29 11:00:34" --stop-datetime="2024-01-29 11:00:37" -v D:\mysql-bin.000005

仔細找BEGIN ... COMMIT ，看看事務到底什么時候開啟的，什么時候提交的

雖然BinLog日志里面不記錄SELECT，但是結合服務端的日志，我發現在執行回調方法查詢業務數據的時候，這個事務還沒有提交

真相大白了

但是明明沒有加事務，為何到現在才提交事務呢？原來是別人調用我的這個方法，但是調用的方法上加了本地事務，所以導致我這段邏輯也整個都在事務中，也就是直到send()方法執行完以后事務才提交，好巧不巧的是發報文是調用遠程Dubbo服務，相當于是異步調用，不受本地事務控制，所以才出現了開頭那一幕，回調方法先回來，此時send()方法還沒執行完，事務沒提交，自然也就查不到

唉。。。