Mybatis與傳統jdbc和Hibernate的比較

lkj41110發表於2016-12-08
MyBatisJDBC
原生態的jdbc的存在的問題：

1、資料庫連線，使用時就建立，不使用立即釋放，對資料庫進行頻繁連線開啟和關閉，造成資料庫資源浪費，影響資料庫效能。
設想：使用資料庫連線池管理資料庫連線。

2、將sql語句硬編碼到java程式碼中(並且分散在各個Java類中)，如果sql語句修改(比如where條件改變)，需要重新編譯java程式碼，不利於系統維護。
設想：將sql語句統一集中配置在xml配置檔案中，即使sql變化，不需要對java程式碼進行重新編譯。

3、向preparedStatement中設定引數，對佔位符號位置和設定引數值，硬編碼在java程式碼中，不利於系統維護。這種方式本身就有一定發 侷限性，它是按照一定順序傳入引數的，要與佔位符一一匹配。但是，如果我們傳入的引數是不確定的（比如列表查詢，根據使用者填寫的查詢條件不同，傳入查詢的引數也是不同的，有時是一個引數、有時可能是三個引數），那麼我們就得在後臺程式碼中自己根據請求的傳入引數去拼湊相應的SQL語句.
設想：將sql語句及佔位符號和引數全部配置在xml中。

4、從resutSet中遍歷結果集資料時，存在硬編碼，將獲取表的欄位進行硬編碼，不利於系統維護。
設想：將查詢的結果集，自動對映成java物件。

5.重複SQL語句問題,幾個功能的SQL語句其實都差不多，有些可能是SELECT後面那段不同、有些可能是WHERE語句不同.
設想：將SQL片段模組化，將重複的SQL片段獨立成一個SQL塊，然後在各個SQL語句引用重複的SQL塊



1、開發上手難度
Hibernate的真正掌握（封裝的功能和特性非常多）要比Mybatis來得難。
在真正產品級應用上要用Hibernate，不僅對開發人員的要求高，hibernate往往還不適合（多表關聯查詢等）。

2、系統調優調優方案對比
Hibernate:
* 制定合理的快取策略；
* 儘量使用延遲載入特性；
* 採用合理的Session管理機制；
* 使用批量抓取，設定合理的批處理引數（batch_size）;
* 進行合理的O/R對映設計

Mybatis：
* MyBatis在Session方面和Hibernate的Session生命週期是一致的，同樣需要合理的Session管理機制。MyBatis同樣具有二級快取機制。 
* MyBatis可以進行詳細的SQL優化設計。

3、SQL優化方面
Hibernate的查詢會將表中的所有欄位查詢出來，這一點會有效能消耗。
Hibernate也可以自己寫SQL來指定需要查詢的欄位，但這樣就破壞了Hibernate開發的簡潔性。

Mybatis的SQL是手動編寫的，所以可以按需求指定查詢的欄位。

總的來說，Hibernate使用的是封裝好，通用的SQL來應付所有場景，而Mybatis是針對響應的場景設計的SQL。Mybatis的SQL會更靈活、可控性更好、更優化。

4、移植性
Hibernate與具體資料庫的關聯只需在XML檔案中配置即可，所有的HQL語句與具體使用的資料庫無關，移植性很好。
MyBatis專案中所有的SQL語句都是依賴所用的資料庫的，所以不同資料庫型別的支援不好。

5、JDBC
Hibernate是在JDBC上進行了一次封裝。
Mybatis是基於原生的JDBC的。Mybatis有執行速度上的優勢。

6、功能、特性豐富程度
Hibernate提供了諸多功能和特性。要全掌握很難。
Mybatis 自身功能很有限，但Mybatis支援plugin，可以使用開源的plugin來擴充套件功能。

7、動態SQL
Mybatis mapper xml 支援動態SQL
Hibernate不支援

實際專案關於Hibernate和Mybatis的選型：
1、資料量：有以下情況最好選用Mybatis
如果有超過千萬級別的表
如果有單次業務大批量資料提交的需求（百萬條及以上的），這個尤其不建議用Hibernate
如果有單次業務大批量讀取需求（百萬條及以上的）(注，hibernate多表查詢比較費勁，用不好很容易造成效能問題)
2、表關聯複雜度
如果主要業務表的關聯表超過20個（大概值），不建議使用hibernate
3、人員
如果開發成員多數不是多年使用hibernate的情況，建議使用mybatis
4、資料庫對於專案的重要程度

如果專案要求對於資料庫可控性好，可深度調優，用mybatis



參考：http://blog.csdn.net/a63297066/article/details/51454726 以及 傳智播客的springMVC視屏

相關文章