這個問題需要真實去使用過，在使用的過程中會發現各自框架的痛點，當你尋找解決方案的時候，你會看其它框架有沒有解決這個問題，這樣你就會領悟到另一個框架的優勢了。

分享一個真實的實戰經歷：

專案剛開始使用原始JDBC方式操作資料庫，自己手動建表不說，手動組裝物件太痛苦，表字段和物件的關係對映寫一堆程式碼，這時候就會想如果有個框架能自動把表和物件關係自動對映，並且能夠封裝好使用方法，在初始化時還能自動建表就更好了。

查詢方案時發現了SpringDataJpa，彷彿打開了新世界的大門，原來透過寫SQL查詢再轉成物件的增刪改查都不用寫了，表字段和物件的對映也不需要手工寫程式碼去匹配可，直接使用，而且可以開啟初始化時自動建立資料庫表。原來需要消耗時間的資料庫操作程式碼現在完全不用寫了，簡單的條件查詢，直接呼叫封裝的方法，快到起飛。但是隨著業務資料的不斷增多，要查詢的條件也越來越複雜，查詢時效越來越慢，漸漸對查詢效能也有了要求。然後就想，在這樣的使用便利上，如果有能便於最佳化資料庫查詢效能的解決方案就好了。

再次找解決方案，發現了MyBatis，感覺發現了另一個新世界。雖然，它不能直接把表和物件的關係對映自動封裝好，但是它可以直接把操作結果對映成需要的物件，只需要建立對應的資料物件DTO就行，並且多表關聯查詢、複雜條件查詢都可以寫SQL解決，最重要的是SQL和邏輯程式碼分析，維護也很方便，SQL最佳化交給專業的DBA就行，再次好用到起飛。

突然有一天，公司強制要求資料庫從oracle換成MySQL，發現Mybatis因為都是寫的純SQL，原來的SQL語法是oracle的，現在都要改，太依賴資料庫了，不便於換資料來源。這時想起了不依賴資料來源的JPA。

總結一下個人看法：

JPA使用完全面向物件的的設計思想，一個表就是一個物件，所有的操作直接操作物件就行，方便、快捷，也不需要關注底層資料來源問題，但是表之間的關係複雜了、查詢複雜了，這樣的操作不是它的強項。

Mybatis是半面向物件、半面向SQL，SQL與邏輯程式碼分離，查詢結果對映成物件，所有操作上層是物件，下層用SQL，資料查詢最佳化上更加實用，因為是寫原生SQL，所以換資料來源可能麻煩。

還是業內的那句老話，沒有絕對“銀彈”，只有適合當前業務發展需要的技術。

沒人用 mybatis plus嗎？強大的程式碼生成器，比jpa還爽的單表查詢，同時還mybatis的xml，靈活的sql不在話下

我覺得這個問題沒啥必要，因為你不想寫sql就用jpa，想寫sql就用mybatis，而不是因為jpa能寫sql就直接不考慮mybatis，兩者本身沒啥矛盾，就看喜好而已。

jpa做聯表分頁查詢和複雜統計很要命，程式碼和sql的耦合性太高，牽一髮而動全身，通用性沒有mybatis好

對jpa不熟的都說mybatis好 而我覺得mybatis唯一好處就是xml集中式管理SQL 除此之外沒法和jpa比。mybatis也就國內流行 原因也不是因為高效什麼的 純粹就是跟風大廠。看看資料就知道

公司目前技術棧用的也是jpa、然後上個月來了個新人，應該是培訓出來的，來之後，我帶了快兩個月了，現在還是每天bb、jpa這是什麼xxxx框架，mybatis多爽啊………自己菜就算了，不願意去提高自己反而去噴框架我是沒想到的，真的被噁心到了

jpa的關聯的幾個問題：

第一個問題，效能問題，關聯查詢效能不行，當然這個可以用圖來解決。寫圖要時間吧？

第二個問題，其他資料儲存的問題，很多業務需要關係的繫結時間，關係生效與不生效的狀態。這個可以透過建立中間類使用兩個manyToone解決。寫中間類會導致很多查詢異常複雜。

第三個問題，條件查詢特別是對被關聯物件的條件過濾，苦不堪言。

也就是說jpa把本來就複雜的查詢，弄的更復雜了。

所以我推薦mybatis plus，比jpa更強大的基礎操作（自動分頁、單表查詢、方法查詢同時可以指定哪些引數為null進行處理、資料物件註解每個欄位在插入和更新時對null值的處理方式），額外還可以使用xml寫sql，不香嗎？jpa的sql在在方法上面，誰看得懂？多表的多條件查詢，動不動100行程式碼，誰看得懂？

用過一年jpa，幾乎所有jpa的功能都玩過了，確實不如mybatis plus。

兩者並沒有明顯的劣勢。從技術角度講我更喜歡Jpa，因為她是標準，功能上會強一些。但是在企業開發架構選型上可能會選擇mybatis，因為他簡單上手快，半吊子程式設計師也能寫出效能不錯的程式碼，學習成本低，也為企業節約成本。反觀Jpa能掌握精髓的人少而貴。。。。

這個要依賴你的資料庫設計，業務的開發模式，以及開發人員的能力。

如果用了JPA，但是最後發現不得不寫越來越多的特殊SQL，經常就是最開始的架構師不能把關了，很多業務實現背離了最開始的設計思想。

一開始想做個workaround，最後就會發現這個倒是成了實際上的實現標準。

JPA傾向於用實體物件去查資料，不便於查詢效能最佳化，而mybatis是寫在配置檔案裡的，只要程式碼邏輯層規範，更容易拿到需要最佳化的sql，而且這樣更符合開發人員的思維邏輯，寫java程式碼的地方就是寫java程式碼的，放sql語句的就是放sql語句的。最重要的一點，在實際專案的實踐中，我能明顯感覺出mybatis查詢的效率要優於JPA和Hibernate。

看了一些其他人的回答，噴子蠻多的，噴了輪子還不夠還要噴別人sb，不會用。沒必要搞歧視，都是輪子，用來解放生產力的。輪子好不好，根據具體場景來。

但是從普適性上來看，如果本來比較簡單的事情，用了工具之後反而更復雜了，那就應該反思了。沒錯，這裡我說的就是jpa。

Jpa確實很多概念都不錯，如果你拿它做個Demo，會發現確實是生產力解放工具，一旦你用到真實專案上，可能就不盡人意了。除非你的專案業務很簡單，不涉及複雜的表關係，因為在單表的模型上jpa確實表現得很優雅，但是哪個實際的業務會如此簡單？做過專案的人都有經驗，不用我多說。

看到這裡，很多人就會噴了，Jpa你會不會用呀，querydsl，enetitygraphql，hql這些都可以用來做複雜查詢，你用過沒？

嗯，其實我現在就在用這些東西。這些東西確實能解決問題，但也只是解決能不能的問題。這就回到前面我所說的，本來簡單事情，反而因為工具更復雜了，原來只用寫sql就能解決的問題，現在是不用寫sql了，但是得寫所謂hql，dsl，graqhql，這就造成你不光要搞懂sql怎麼寫，還要搞懂用這些玩意怎麼去間接生成你想要sql。

其實用上面這些和jpa捆綁在一起的東西的，本身就是jpa短板導致的無奈之舉，這些東西本身和jpa理念是互相矛盾的。

說到這，有些人的言論就變成了，你不會用怪誰，水平不行怪輪子。這是混淆概念，好不好用是工具自身便捷與否，和用的人水平有什麼關係。

所以，究竟jpa好不好用，得看你用來做什麼了。

jpa最不好的地方就是關聯是定死的，但實際應用中同一個關係在不同的時候是活的，導致用的時候非常彆扭。明明是物件模型，搞出來個查詢語言卻還是仿造關係型的，寫的時候還要先考慮sql再轉成jpql，完全多此一舉。

mybatis也有自己的問題，最近發現spring data jdbc是個不錯的選擇，雖然暫時還不太成熟。

spring data jpa在複雜查詢上可以使用query+new 構造方法或者檢視的方式去查詢，至於說效率，我想應該是在POJO中使用@OneToMany或者@ManyToMany的註解導致的，一般情況下儘量使用@ManyToOne就可以了

個人認為mybatis可以做到程式碼與SQL解耦，單表查詢用jpa倒是沒什麼，要是寫統計或者複雜查詢之類的jpa就不太友好了，需要程式碼邏輯跟SQL耦合起來，程式碼可讀性和可維護性不好。最近基於jdbcTemplate做了一套自定義動態查詢，也將sql放在了配置檔案中，也是為了降耦和提高程式碼可讀性，還可以根據業務場景定製很多功能。

國內的設計思路是table driven的，簡單來說，用資料表定邏輯，用模型做實現，實際這是和麵向物件相反的思路。mybatis所謂的靈活性在大多數工程師手裡就是不用考慮模型如何設計，“反正我用原生sql都能解決”，模型設計的爛的一逼，全靠sql去修修補補。而jpa是完全object driven的思路，前期設計的缺陷會很制約後續開發，並且不同的資料庫可做不同的實現（實際是哪怕是redis也是一樣的）。回答幾個常見sb問題。

1.jpa表連線行為不確定，難以控制。

你確定你用過spring data jpa？不知道有EntityGraph ？傻瓜到這種程度了還能咋的。

2.jpa子查詢不好實現。

我估計你都沒用過吧？spring data jpa的子查詢既可以單獨定義檢視，也可以做subquery，甚至直接用jpql。

3.jpa不好最佳化。

我真不信99%得最佳化能超過spring data jpa的最佳化，尤其是一般般的程式設計師能別把最佳化放嘴上麼，連mysql的鎖都搞不清楚，表設計的跟坨屎一樣還天天原生sql，覺得自己很牛逼麼？jpa是可以把表屬性反應到物件的，天然就有執行時最佳化的底子在，ORM能發展的空間太大了，稍微有點技術認知的都知道ORM會優勢越來越大。稍微有些經歷的程式設計師都知道現在是先說好維護才說其他的，能解決效能的方法太多了好麼。

最後，難道不知道現在提倡ORM+CQRS麼？請問，有啥複雜的解決不了，都不需要native sql介入好麼。