MyBatis Select 性能基準測試：XML Mapper vs 注解 Mapper vs 原生 JDBC vs DBCP

MyBatis Select 性能基準測試：XML Mapper vs 注解 Mapper vs 原生 JDBC vs DBCP

通過編寫基準測試代碼，對比 MyBatis 不同映射方式、原生 JDBC 及 DBCP 連接池在單次/多次開關 Session 場景下的查詢耗時。

測試環境與代碼結構

• 目標表：ui_button，主鍵 button_id
• 測試次數：1, 2, 10, 100, 200, 1000
• 指標：總耗時（毫秒）

核心測試邏輯片段

// 1. XML Mapper 每次開關 Session
for (int i=0; i

Mapper 定義
<!-- XML -->
<select id="selectbutton" resultType="UI" useCache="false">
  select button_id, text_value from ui_button where button_id=#{id}
</select>

<!-- 註解 -->
@Select("select button_id, text_value from ui_button where button_id=#{id}")
@Options(useCache=false)
UI2 selectOne(String id);

測試結果分析（摘要）



  
MyBatis 較原生 JDBC 慢約 2 倍，主要開銷在反射映射、緩存管理、動態代理等框架層面。
  
單次 Session 復用顯著優於每次開關，生產環境務必使用連接池與 Session 復用策略。
  
註解 Mapper 與 XML Mapper 性能接近，選擇取決於團隊習慣與 SQL 複雜度。
  
DBCP 連接池單次連接表現最優，但測試未模擬併發，實際高併發下連接池優勢更明顯。


結論與建議

  
MyBatis 為開發效率與可維護性付出的性能代價在可接受範圍內。
  
避免在循環中重複 openSession()/close()，應在 Service 層控制事務邊界。
  
對極度敏感的查詢可考慮原生 JDBC 或緩存策略。
  
與 .NET Dapper 等輕量 ORM 相比差距較大，但功能定位不同，不可直接類比。