JPA性能：實體或實體ID作為查詢參數？

Question

假設有兩種實體類型： Book （帶有主鍵bookId ）和Author （帶有主鍵authorId ）。 一位作者寫了0 ... n本書。 所以， Author在引用Book使用@ManyToOne 。

如果我們想要檢索某個作者編寫的所有書籍，我們可以在JPQL中做兩件事（例如NamedQuery）：

1. SELECT b FROM Book b WHERE b.author = :author （entity as parameter）
2. SELECT b FROM Book b WHERE b.author.authorId = :authorId （實體的主鍵ID作為參數）

在第一個選項中，我們必須注意傳遞的對象實際上是Author類型，並且它已經有一個主鍵。

但是：在上面提到的兩個選項中，性能是否存在差異？ 我猜（2）更便宜，但（1）可能更容易針對JPA提供商進行優化。 是否有關於此問題的性能測試或文獻？

我們可以假設Author實例（我們想要搜索的書籍）已經被加載（例如，在響應中查看他/她的個人資料），因此沒有額外的代碼編寫工作來傳遞整個對象或只是它的書籍搜索方法的ID。 但是執行速度有差異嗎？ 可能取決於使用的JPA提供商？

Answer 1

我測試了兩個查詢，結果sql是一樣的。

回答你問題的第二部分 - 有很多相關的文獻，但我特別推薦Pro JPA 2, 2nd Edition by Mike Keith , Merrick Schincariol 。

如果您需要手動執行測試查詢，則可以查看JPA查詢產生的SQL查詢。 一種方法是了解您的JPA提供程序並查看他為此目的提供的選項（例如，Hibernate提供了選項hibernate.show_sql ）。 第二個選項（在我看來 - 更好）是使用諸如log4jdbc工具，它是JDBC驅動程序和持久性提供程序之間的附加層（簡化），並且可以記錄發送到數據庫的所有查詢及其參數。 它還可以測量每個查詢的時間花費，因此我認為它是性能測試的理想工具。