iBatis 批次處理深度優化：原理解析、多表批次陷阱與底層原始碼修改實現真正多表 Batch 支援

為什麼需要批次處理？

大量資料操作 (插入/更新/刪除) 時，批次處理可將多條 SQL 合併為單次網路往返，效能提升可達數十倍甚至上百倍。實例：刪除 5 萬筆資料，無批次需 30 分鐘，啟用批次 < 1 分鐘。

JDBC 原生批次機制回顧

// 關鍵：關閉自動提交
conn.setAutoCommit(false);

PreparedStatement stmt = conn.prepareStatement("INSERT INTO employees VALUES (?, ?)");

for (Employee e : employees) {
    stmt.setInt(1, e.getId());
    stmt.setString(2, e.getName());
    stmt.addBatch();  // 累積到批次
}

int[] updateCounts = stmt.executeBatch();  // 單次發送執行
conn.commit();

核心原理：PreparedStatement 內部維護命令列表，executeBatch() 一次性提交給資料庫執行。

iBatis 批次支援現狀與 API

SqlMapClient client = ...;
client.startBatch();  // 開啟批次模式

for (int i = 0; i < 2000; i++) {
    client.delete("deleteOrder", i);  // 映射檔中定義的 statement
}

client.executeBatch();  // 執行批次

底層實現委託 JDBC PreparedStatement.addBatch()/executeBatch()。

致命陷阱：單批次僅支援單一 SQL 陳述式

錯誤寫法：單迴圈多表操作 (代碼 1)

sqlWrapper.startBatch();
for (int i = from; i < to; i++) {
    sqlWrapper.delete(DELETE_STRG_CNTR_BL, list.get(i));  // SQL 1
    sqlWrapper.delete(DELETE_STRG_CNTR, list.get(i));     // SQL 2
    sqlWrapper.delete(DELETE_CNTR, list.get(i));          // SQL 3
}
sqlWrapper.execBatch();

正確但醜陋寫法：多迴圈單表操作 (代碼 2)

sqlWrapper.startBatch();
for (int i = from; i < to; i++) sqlWrapper.delete(DELETE_STRG_CNTR_BL, list.get(i));
for (int i = from; i < to; i++) sqlWrapper.delete(DELETE_STRG_CNTR, list.get(i));
for (int i = from; i < to; i++) sqlWrapper.delete(DELETE_CNTR, list.get(i));
sqlWrapper.execBatch();

根因深度剖析：iBatis 內部 Batch 實現原始碼

來源：com.ibatis.sqlmap.engine.execution.BatchExecutor

public void addBatch(RequestScope request, Connection conn, String sql, Object[] parameters) {
    PreparedStatement ps = null;
    
    // 關鍵判斷：僅比較 SQL 字串 hashCode 與長度
    if (currentSql != null 
        && sql.hashCode() == currentSql.hashCode() 
        && sql.length() == currentSql.length()) {
        
        // 同一 SQL：復用最後一個 PreparedStatement
        int last = statementList.size() - 1;
        ps = (PreparedStatement) statementList.get(last);
    } else {
        // 不同 SQL：建立新 PreparedStatement
        ps = conn.prepareStatement(sql);
        currentSql = sql;
        statementList.add(ps);
    }
    
    request.getParameterMap().setParameters(request, ps, parameters);
    ps.addBatch();
    size++;
}

核心問題

1. SQL 字串作為唯一鍵：不同表的 delete SQL 字串不同，每次進入 else 分支建立新 PreparedStatement
2. 單迴圈多表 = 大量 PreparedStatement：批次大小 N、M 張表 → N×M 個 PreparedStatement
3. 資料庫游標耗盡：每個 PreparedStatement 佔用一個資料庫游標。N=5000、M=10 → 50,000 游標，觸發 ORA-01000: maximum open cursors exceeded
4. 批次效能歸零：實際上每個 SQL 只累積 1 條資料就執行，失去批次優勢

解決方案：修改底層原始碼支援真正多表批次

設計思路：SQL 字串 → PreparedStatement 映射表

將 List<PreparedStatement> statementList 改為 Map<String, PreparedStatement> stmtMap

修改後的核心邏輯

public void addBatch(RequestScope request, Connection conn, String sql, Object[] parameters) {
    PreparedStatement ps = stmtMap.get(sql);  // O(1) 查找
    
    if (ps == null) {
        ps = conn.prepareStatement(sql);
        stmtMap.put(sql, ps);
    }
    
    request.getParameterMap().setParameters(request, ps, parameters);
    ps.addBatch();
    size++;
}

完整修改步驟

1. 下載 iBatis 原始碼 (如 ibatis-2.3.4.726-src.zip)
2. 定位 BatchExecutor.java (通常在 com.ibatis.sqlmap.engine.execution 套件)
3. 修改欄位：private List statementList; → private Map<String, PreparedStatement> stmtMap = new HashMap<>();
4. 修改 addBatch() 方法為上述邏輯
5. 修改 executeBatch()：遍歷 stmtMap.values() 呼叫 ps.executeBatch()
6. 修改 close()：遍歷關閉所有 PreparedStatement
7. 重新編譯打包 ibatis-sqlmap-xxx.jar，替換專案依賴

修改後效果驗證

// 現在單迴圈多表真正享受批次優勢
sqlWrapper.startBatch();
for (int i = from; i < to; i++) {
    sqlWrapper.delete(DELETE_STRG_CNTR_BL, list.get(i));  // 復用 PS1
    sqlWrapper.delete(DELETE_STRG_CNTR, list.get(i));     // 復用 PS2
    sqlWrapper.delete(DELETE_CNTR, list.get(i));          // 復用 PS3
}
sqlWrapper.execBatch();  // 僅 3 個 PreparedStatement，各自執行 executeBatch()

• PreparedStatement 數量：從 N×M 降為 M (表數)
• 資料庫游標：從 N×M 降為 M
• 網路往返：M 次 executeBatch()，每次批次傳輸 N 條資料
• 程式碼簡潔度：單迴圈、無重複、符合直覺

生產環境驗證與風險控管

替代方案對比

總結

iBatis 批次處理的核心限制在於「以 SQL 字串為鍵的 PreparedStatement 快取機制」。透過將 List 改為 Map，即可實現真正的多表批次支援，將 PreparedStatement 數量從 O(N×M) 降為 O(M)，徹底解決游標耗盡與效能歸零問題。此修改僅涉及 BatchExecutor 核心類約 20 行代碼變更，風險可控、收益顯著。對於深度依賴 iBatis 且面臨大量多表批次場景的專案，這是一個高性價比的技術債償還方案。