接着上一篇的疑問，難道jpa真的就能無敵到能解決所有sql查詢的情況嗎？這次終於有否定的答案了，還是不行的。讓我們在看看jpa怎麼實現自動查詢的。
User findByRealName(String realName);
User findByUsernameOrEmail(String username,String email);
可以看到我們是在接口中聲明的方法，是的，也就是說這些查詢條件在應用運行過程中，沒法做到動態控制使用哪些查詢條件。我們可以理解爲jpa的這種查詢只能應用在查詢條件事先就確定並固定的場景中，另外查詢條件不能太多。想象一下，如果有10個或者20個查詢條件，查詢方法的名稱得有多長？
所以jpa還是提供了另外兩種查詢解決方案，第一個是JPQL，一種類似hibernate的HQL的查詢語句；第二個是Specification，一種對象查詢條件方式。
JPQL用法跟傳統的SQL查詢沒什麼區別，只是語法不一樣而已，我們就在jpa的方法聲明時，通過@Query就可以指定JQPL，不用jpa自動生成，並且還能有佔位符的概念。我們就來看一個例子。
UserRepository文件中添加
這樣就可以完成JPQL的簡單使用。
我們還是重點來看看Specification的方式，那麼先看看Specification是什麼？打開源碼，發現是一個接口。就一個toPredicate方法，返回的Predicate對象。
那麼什麼地方可以使用這個接口呢？通過源碼發現SimpleJpaRepository就有方法。但是這兩個方法是JpaSpecificationExecutor接口定義的，跟JpaRepository是兩回事。
所以咱們UserRepository想要使用Specification的方法還需要繼承JpaSpecificationExecutor，這樣就可以直接使用了，那我們就來通過單元測試進行動態查詢吧。
UserRepository 繼承JpaSpecificationExecutor
public interface UserRepository extends JpaRepository<User, Long> ,JpaSpecificationExecutor<User>
單元測試添加
Specification接口使用匿名類的方式，實現了動態查詢條件封裝的工作，加上jpa默認自帶的查詢方法，能夠輕鬆的解決動態查詢的需求。這種方式從操作方式上，確實也是面向對象的思想，咱們不用直接跟SQL打交道。至少jpa真的能在日常開發工作中，讓我們不用太多關心數據庫知識，就能解決絕大多數的需求開發工作。
但是數據庫的使用場景是非常多的，可能很多實踐經驗豐富的同學，已經細心的發現了，我們一直在討論JPA對於單表的數據庫操作。實際工作中，業務複雜度很高，業務模型需要進行數據分類，也是出於數據庫效率因素考慮，常常需要多表操作。那麼如何解決多表查詢的問題呢？咱們也放到下一篇再進行討論。
回顧總結，jpa在接口中聲明查詢方法的方式（JpaRepository），只能解決查詢條件數量少並且固定的場景，沒法根據實際需要，進行動態查詢條件組合的場景。要解決動態查詢問題，jpa提供了Specification的方案，咱們的接口需要繼承JpaSpecificationExecutor，也是使用面向對象的操作方式封裝查詢條件。還有一種JPQL的方案，跟傳統SQL其實沒什麼區別，當然它還是具備跨數據庫的優點，但是如果真的使用到了JPQL，還不如直接使用原生SQL，免得增加大家的學習成本。