MyBatis 進階映射與查詢緩存完整指南

MyBatis 核心架構與執行流程

MyBatis 作為一款優秀的持久層框架，其核心執行流程包含五個關鍵步驟：首先載入配置文件（SqlMapConfig.xml）建立 SqlSessionFactory 會話工廠，採用單例模式確保全局唯一；接著透過 SqlSessionFactory 創建 SqlSession，該物件線程不安全，建議在方法體內使用；隨後呼叫 SqlSession 方法操作資料庫，事務提交需顯式調用 commit()；最後釋放資源關閉 SqlSession。

Mapper 代理開發模式

推薦使用 Mapper 代理開發，開發者只需編寫 Mapper 接口（DAO 接口）與對應的映射文件，遵循四項規範：namespace 對應接口全限定名、statement id 對應方法名、parameterType 對應輸入參數類型、resultType 對應返回值類型。

訂單商品數據模型深度解析

四步分析法

• 熟悉各表記錄的業務數據內容
• 掌握非空字段、外鍵字段等關鍵字段設計
• 梳理資料庫層面的外鍵關係
• 基於具體業務場景分析表間業務關係

核心實體關係圖譜

用戶表 ↔ 訂單表：一對多（用戶下單） / 一對一（訂單歸屬）
訂單表 ↔ 訂單明細表：一對多（訂單包含明細） / 一對一（明細歸屬）
訂單明細表 ↔ 商品表：一對一（明細對應商品） / 一對多（商品被多次購買）
跨表關係：訂單與商品透過明細表關聯，用戶與商品形成多對多關係

高級結果映射實戰

一對一查詢：resultType vs resultMap

resultType 方案：需建立包含所有查詢欄位的自定義 POJO（如 OrdersCustom），簡單直接但無法處理巢狀對象。
resultMap 方案：使用 <association> 將關聯查詢的用戶信息映射到 Orders 對象的 user 屬性中，支援延遲加載，適合對結果結構有特殊要求的場景。

一對多查詢：collection 標籤應用

透過 <collection> 將多筆訂單明細映射到 Orders 對象的 List<OrderDetail> 屬性中，配合 extends 繼承復用基礎映射，實現「訂單不重複、明細歸屬清晰」的物件圖構建。

多對多查詢：巢狀集合映射

用戶 → 訂單列表 → 明細列表 → 商品信息，三層 <collection> + <association> 巢狀結構，完美呈現「用戶購買商品明細」的複雜業務視圖。

延遲加載機制詳解

核心原理：先查主表（單表查詢），按需觸發關聯查詢。配置 <association select="..." column="..."> 指定延遲加載的 statement，需在 SqlMapConfig.xml 開啟 lazyLoadingEnabled。實際開發中建議在 Service 層手動控制分步查詢，避免框架層面的魔法行為帶來不可控風險。

查詢緩存體系全景

一級緩存（SqlSession 級）

基於 HashMap 實現，同一 SqlSession 內重複查詢自動命中。執行增刪改或 commit() 會清空緩存，確保數據一致性。Spring 整合後，Service 方法對應一個 SqlSession，天然支援業務事務內的緩存複用。

二級緩存（Mapper 級）

跨 SqlSession 共享，按 namespace 隔離。需在核心配置開啟 cacheEnabled 並在具體 Mapper 中配置 <cache/>。POJO 必須實現 Serializable。適用於「高頻查詢、低實時性要求」場景（如統計報表、歷史帳單），可配合 flushInterval 定時刷新。

緩存精細控制

• useCache="false"：禁用特定查詢的二級緩存
• flushCache="true"：增刷改操作後自動刷新緩存，防止髒讀

Ehcache 整合與分佈式擴展

MyBatis 預設緩存基於記憶體，集群環境下需整合 Ehcache 等分佈式緩存框架，透過實現 Cache 接口實現緩存數據集中管理，配置 ehcache.xml 定義磁盤存儲、淘汰策略（LRU/LFU/FIFO）等參數。

二級緩存局限性與最佳實踐

Mapper 級緩存粒度較粗，無法實現「單條商品變更僅刷新該商品緩存」。建議：業務層引入 Redis 等中間件，按業務鍵值精細控制緩存更新；或利用 MyBatis 定時刷新機制作為輔助手段。