答：Hibernate和Mybatis都是orm對象關系映射框架，都是用于將數據持久化的框架技術。
Hiberante較深度的封裝了jdbc，對開發者寫sql的能力要求的不是那么的高，我們只要通過hql語句操作對象即可完成對數據持久化的操作了。
另外hibernate可移植性好，如一個項目開始使用的是mysql數據庫，但是隨著業務的發展，現mysql數據庫已經無法滿足當前的繡球了，現在決定使用Oracle數據庫，雖然sql標準定義的數據庫間的sql語句差距不大，但是不同的數據庫sql標準還是有差距的，那么我們手動修改起來會存在很大的困難，使用hibernate只需改變一下數據庫方言即可搞定。用hibernate框架，數據庫的移植變的非常方便。
但是hibernate也存在著諸多的不足，比如在實際開發過程中會生成很多不必要的sql語句耗費程序資源，優化起來也不是很方便，且對存儲過程支持的也不夠太強大。但是針對于hibernate它也提供了一些優化策略，比如說懶加載、緩存、策略模式等都是針對于它的優化方案。
Mybatis 也是對jdbc的封裝，但是封裝的沒有hibernate那么深，我們可以再配置文件中寫sql語句，可以根據需求定制sql語句，數據優化起來較hibernate容易很多。
Mybatis要求程序員寫sql的能力要相對使用hibernate的開發人員要高的多，且可移植性也不是很好。
涉及到大數據的系統使用Mybatis比較好，因為優化較方便。涉及的數據量不是很大且對優化沒有那么高，可以使用hibernate

1) 對于每個實體，需要寫一個dao接口文件。編碼復雜度C(n)=O(n)，即會隨實體的增長，編碼量呈線性增長。當n較大時，會增加許多人力物力消耗。
2) 實體Javabean與DB表的map映射文件太多；或者，實體Javabean文件注解用得太泛濫，太多注解難以記憶，增加開發人員負擔。Mybatis中實體對應的mapper文件，代碼太多，雖然可以自動生成，但閱讀性太差。編寫和調試sql語句需要大量時間，降低開發效率。
3) 實體操作默認的條件，一般以id作為條件，但開發時，一般不會提前知道id；若用其它條件作為查詢等，需要在接口文件新定義方法。如一個實體有10個字段，2個字段組合一個查詢方法，則有 =45個查詢方法；若算上3個字段，4個字段的組合，則更多。
4) 接口文件定義好后，若后期發現定義的方法不能滿足需求，需要定義新的方法，又要修改接口文件；若是系統已經上線，還要需要重新開發、測試、發布等。
5) 當一個表新增一個字段，刪除一個字段，或修改一個字段時，Mybatis需要修改mapper映射文件，幾乎其中的每個方法都要修改。修改字段，Mybatis在編譯期不能自動發現錯誤。Hibernate通過xml文件或有注解的Javabean文件，同步DB的表結構時，也不能實現刪除和更新。更新時，它是忽略原來的字段，然后新增一個字段，除非刪除了表，重新再建一次。要是DB的表已保存了數據，不能刪除，還是要手動去更改數據庫。
6) Hibernate想讓ORM框架做完DB所有的事情，反而使框架變得太復雜，不易于使用。Hibernate的ORM模型不能查詢一部分數據，即使用戶沒有使用到，也會將所有關聯的數據都查詢出來。
7) Hibernate的概念太復雜，學習成本高，更新會先查詢再更新，n+1問題。Mybatis即使進行單表的Suid操作也需要人工寫sql或生成sql文件，需要維護的sql太多。
8) 需要寫很多的判斷字段是否為空（null) ，是否是空字符串的語句；開發人員需要承擔太多類似的重復，乏味的編程工作。