1. JPA

1.1. 性能直接受底層JDBC驅動性能的影響

1.2. 性能提升是通過改變實體類的位元組碼來實現的

1.2.1. 在類載入到JAR文件或者由JVM運行之前增強位元組碼的方法

1.2.1.1. 在編譯過程中完成的

1.2.1.2. 在實體類編譯完成後，它們會被傳遞給一個特定實現的後置處理器

1.2.1.3. 該後置處理器會“增強”位元組碼，產生一個修改過的類文件，其中包含所需的優化

1.2.2. 在類被載入到JVM時動態增強位元組碼的方法

1.2.2.1. 在JVM中運行一個代理，當類被載入時，代理會收到通知並介入類載入的過程，在位元組碼定義類之前對其進行修改

1.2.2.2. 代理是在應用程式的命令行上指定的

2. 優化JPA寫

2.1. 寫入更少的欄位

2.2. 可以從限制資料庫的寫入調用數量中獲益

2.3. 語句池可以在JPA層面或JDBC層面實現

2.3.1. 應該首先嘗試在JDBC層面實現

2.3.2. 如果JDBC驅動能夠提供語句池，通常最好在驅動中啟用語句池，並將從JPA的配置中刪除語句池配置

2.4. JDBC驅動不能自動實現語句批處理

2.4.1. 設置size屬性

2.4.2. JPA的批量更新可以用聲明的方式在persistence.xml文件中完成

2.4.3. 應用程式可以定期調用實體管理器的flush()方法，這個調用會立即執行所有需要批量處理的語句

3. 優化JPA讀

3.1. 讀取更少的數據

3.1.1. 因為有些數據不需要

3.1.2. 目的

3.1.2.1. 在檢索實體時可以讓SQL更快

3.1.2.2. 可以節省大量記憶體，從而減少了GC壓力

3.1.3. 指定需要延遲載入的相關欄位

3.1.3.1. 當一個實體被檢索時，帶有延遲載入註解的欄位將被排除在用於載入數據的SQL之外

3.1.3.2. 對於基本類型的簡單列，很少使用

3.1.3.3. 基於BLOB或基於CLOB的大型對象考慮使用

3.1.3.4. 延遲載入註解最終只是對JPA實現的建議

3.1.3.4.1. JPA實現可以自由決定資料庫是否立即提供該數據

3.2. 一次讀取更多的數據

3.2.1. 因為將來肯定需要這些數據

3.3. 提取組（fetch group）

3.3.1. 非標準JPA

3.3.2. 可以將某些延遲載入欄位指定為一組，在其中一個欄位被訪問時，整個組都會被載入

3.3.3. 多個獨立的欄位組，每個組會在需要時被載入

3.4. 立即提取（eager fetching）

3.4.1. 當獲取一個實體時，其他相關實體的數據也應該被返回

3.5. 在查詢中使用JOIN

3.5.1. 特殊的@JoinFetch註解，它也可以用於連接提取關係

3.5.2. 選擇立即載入關係時，可以使用命名查詢來發出一條使用JOIN的SQL語句

3.6. 處理結果集

3.6.1. 一次獲取所有結果

3.6.2. 在程式遍歷查詢結果時一次獲取一個結果

3.6.3. 一次獲取幾個結果

3.7. 命名查詢的速度更快

3.7.1. JPA實現幾乎總是使用帶有綁定參數的預處理語句，同時利用語句緩存池

4. JPA緩存

4.1. 提供一個中間層來緩存後端資料庫返回的數據

4.1.1. 緩存頻繁使用的數據可以大幅縮短客戶端的響應時間

4.1.2. JPA緩存只對通過主鍵訪問的實體進行操作

4.2. 一級緩存

4.2.1. L1緩存

4.2.2. 實體管理器中的本地緩存

4.2.3. 幾乎不需要優化

4.2.4. 在所有JPA實現中都是開啟的

4.3. 二級緩存

4.3.1. L2緩存

4.3.2. 全局緩存

4.3.3. 在所有的實體管理器之間共用的

4.3.4. 不是所有的JPA實現都會預設開啟它

4.3.5. L2緩存會自動為應用程式緩存實體

4.3.6. 當有很大的JPA L2緩存時，堆的優化對於良好的性能就相當重要了

4.4. 通過查詢檢索到的數據不會保存在L2緩存中

4.4.1. 即使JPA實現支持查詢緩存，實體本身也不會存儲在L2緩存中，也不能在隨後調用find()方法時被返回

4.4.2. 只有在每次執行查詢時，查詢中使用的參數完全相同的情況下，查詢緩存才會起作用

4.4.3. 除非正在使用的JPA實現支持查詢緩存，否則使用JOIN查詢經常會對性能造成負面影響，因為它沒有利用L2緩存

4.4.4. 從長遠來看，避免查詢是有益的

4.5. 當所有的數據都被使用時，立即載入和延遲載入的性能基本相同

4.6. 當關係數據沒有被實際使用時，延遲載入會節省一些時間

4.6.1. 特別是在迴圈第一次執行時

4.6.2. 迴圈的後續執行並不會節省時間

4.6.2.1. 在這些後續的迭代中，立即載入的代碼並沒有重新載入數據，它是從L2緩存中查找的數據

4.7. 如果實體都不是通過查詢檢索到的，那麼在初始的預熱期之後，通過L2緩存可以訪問所有的實體

4.7.1. 即使SQL語句返回多行數據，JPA仍然能夠緩存實體，這和執行查詢不同

4.7.2. 如果通過遍歷實體來預熱L2緩存，不要單獨遍歷相關實體，通過訪問關係來遍歷更簡單

4.8. 如果緩存消耗了太多記憶體，就會給GC造成壓力

4.8.1. 設置緩存大小的選項

4.8.1.1. 針對全局的

4.8.1.2. 針對每個實體的

4.8.2. 另一種可用方法是讓L2緩存使用軟引用或/和弱引用

4.8.2.1. 比為每個實體找到最佳大小要容易一些

4.8.2.2. 弱引用在任何GC操作中都會被回收

5. Spring Data

5.1. 關係資料庫和NoSQL資料庫的資料庫訪問模塊集合

6. Spring Data JDBC

6.1. JPA的一個簡單替代方案

6.2. 提供了類似於JPA的實體映射

6.3. 沒有緩存、延遲載入或臟實體跟蹤等功

7. Spring Data JPA

7.1. 標準JPA的包裝器

7.2. 減少開發人員需要編寫的模板代碼量

7.2.1. 提高開發人員的效率

7.2.2. 並不能真正影響應用程式性能

8. Spring Data for NoSQL

8.1. 各種NoSQL和類NoSQL技術的連接器

8.2. MongoDB

8.3. Cassandra

8.4. Couchbase

8.5. Redis

9. Spring Data R2DBC

9.1. 允許對Postgres、H2和Microsoft SQL Server資料庫進行非同步訪問

9.2. 遵循典型的Spring Data編程模型

9.3. 不是直接使用JDBC

9.4. 和Spring Data JDBC類似

9.5. 通過倉庫中的簡單實體進行訪問

9.6. 沒有緩存、延遲載入和JPA的其他功能