MyBatis 核心缺陷深度剖析：DTD 限制、版本兼容、插件機制、緩存設計、批量執行與數據庫兼容性

MyBatis 並不完美：六大核心缺陷深度解析

MyBatis 作為金融 IT 領域事實標準的持久層框架，以輕量、SQL 掌控力強著稱。但深入源碼與實戰後，會發現其設計中存在多個值得商榷甚至稱為「缺陷」的決策。本文從架構視角剖析六大核心問題。

1. 配置驗證仍停留在 DTD 時代

現狀：MyBatis 3.x 仍使用 DTD (Document Type Definition) 驗證 XML 配置（<!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN" ...>）。

痛點：

• DTD 不支援命名空間，擴展性極差
• 無法表達複雜約束（如元素出現次序、資料型別）
• IDE 智能提示弱，編寫體驗差
• Spring 早已完成 DTD → XSD 遷移，MyBatis 卻遲遲不跟進

影響：自定義標籤擴展極其困難，第三方整合需繞過驗證或犧牲 IDE 支援。

2. 版本兼容性策略混亂：微版本號破壞二進制兼容

案例：3.3.0 → 3.4.0（次版本號升級，按語義化版本應保證向下兼容）

// 3.3.0
Statement prepare(Connection connection) throws SQLException;

// 3.4.0 - 直接在原方法新增參數！
Statement prepare(Connection connection, Integer transactionTimeout) throws SQLException;

後果：

• 實現 StatementHandler 介面的自定義插件/擴展直接編譯報錯
• 運行時 NoSuchMethodError，極難排查
• 類似破壞性變更不止一處（ResultSetHandler、Executor 等核心介面均有）

建議：遵循「介面不變、新增介面」原則，或提供適配器模式平滑過渡。

3. 插件機制：過度泛化的 Interceptor 導致結構混亂

現狀：單一 Interceptor 介面 + @Intercepts + @Signature 註解攔截多組件多方法。

缺陷：

• 違反單一職責：迫使開發者將 StatementHandler、ResultSetHandler、ParameterHandler 等不同關注點的攔截邏輯塞進同一類
• 編譯期不安全：@Signature 註解中的型別/方法名/參數列表均為字串，拼寫錯誤編譯通過，啟動時才報錯
• 版本脆弱：結合問題 2，目標方法簽名一變，插件即失效

更好設計：針對每個組件定義專用擴展介面（StatementHandlerPlugin、ResultSetHandlerPlugin），編譯期強類型檢查。

4. 緩存設計：無條件計算 CacheKey 的效能浪費

現狀：無論是否啟用二級緩存、是否命中、是否更新，CachingExecutor 都會無條件計算 CacheKey（包含 SQL、參數、RowBounds 等雜湊）。

代碼證據：

// CachingExecutor.query()
CacheKey key = createCacheKey(ms, parameterObject, rowBounds, boundSql);
// 之後才判斷 cache.getObject(key)...

影響：高併發下，大量無意義的雜湊計算佔用 CPU，且緩存本身設計簡陋（無分區、無淘汰策略配置、序列化開銷大），實際生產多建議關閉，改用 Redis/Caffeine。

5. 批量執行：事務內無法混合普通 SQL 與 Batch SQL

JDBC 原生行為：同一 Connection、同一事務中，可交替執行 executeUpdate() 和 addBatch()/executeBatch()，回滾正常。

MyBatis 限制：SqlSession 內部維護 ExecutorType（SIMPLE/REUSE/BATCH），同一事務不可切換執行模式。嘗試混合會拋異常：Cannot change executor type within a transaction。

場景痛點：主表單條插入 + 明細批量插入，被迫拆分事務或放棄 Batch 模式。

6. 數據庫兼容性：道德制高點下的推卸責任

現狀：MyBatis 宣稱「SQL 由開發者掌控，兼容性由開發者負責」。

反駁：優秀框架應提供輔助兼容能力而非完全放任：

• Oracle DECODE → 標準 CASE WHEN 自動轉換標籤
• 分頁方言抽象：MySQL LIMIT / Oracle ROWNUM / PostgreSQL OFFSET/FETCH 統一標籤
• 關鍵字轉義、型別映射擴展點

核心矛盾：又回到問題 1——擴展性極差（DTD、插件機制），導致使用者無法優雅擴展兼容層。

總結與建議

結語：MyBatis 以「簡單、直接、掌控 SQL」贏得市場，但其架構決策中的歷史包袱（DTD、單一 Interceptor、緩存設計）在現代雲原生、高併發、多數據庫場景下顯得力不從心。理解其缺陷，不是為了否定，而是為了在技術選型、架構演進、踩坑避雷時做出更理性的判斷。