讀Java性能權威指南（第2版）筆記05_資料庫性能JDBC

1.影響資料庫應用程式性能最重要的因素

1.1.JDBC驅動

1.1.1.JPA底層使用了JDBC

2.瘦驅動

2.1.為了讓Java應用程式的記憶體占用很小

2.2.依賴資料庫伺服器來完成更多的處理工作

3.胖驅動

3.1.工作從資料庫移至Java應用程式

3.2.進行更多處理、消耗更多記憶體

4.JDBC連接配接池

4.1.規則1：讓應用程式中的每個線程都有一個連接配接

4.1.1.在伺服器中，在初始時将線程池和連接配接池設定為相同的大小

4.1.2.在獨立應用程式中，可以根據應用程式建立的線程數确定連接配接池的大小

4.1.3.程式中的任何線程都不必等待可用的資料庫連接配接，并且資料庫有足夠的資源來處理應用程式施加的負載

4.2.資料庫是瓶頸，規則1就不适用了

4.2.1.用連接配接池限制發送到小規模資料庫的工作量

4.2.1.1.應用程式線程可能需要等待一個空閑的連接配接

4.2.1.2.如果資料庫沒有被壓垮，系統的總吞吐量會最大化

4.3.初始化連接配接對象的成本很高

4.3.1.在Java中它們經常被池化

4.3.2.在池化對象所占用的記憶體和池化将觸發的額外GC數量之間取得适當的平衡是非常重要的

4.4.優化連接配接池很重要

4.4.1.減少對垃圾回收器産生不利影響

4.4.2.減少對資料庫的性能産生不利影響

5.驅動類型

5.1.1型驅動

5.1.1.ODBC和JDBC之間的橋梁

5.1.1.1.Open Database Connectivity，開放資料庫互連

5.1.2.一個程式必須使用ODBC與資料庫進行通信，就必須使用

5.1.3.性能一般很差

5.2.3型驅動

5.2.1.純Java語言編寫

5.2.2.為特定的架構設計

5.2.3.有個中間件能提供中間轉換過程

5.2.4.中間件可以位于DMZ中，為資料庫連接配接提供額外的安全保障

5.3.2型驅動

5.3.1.使用原生庫來通路資料庫

5.3.2.允許Java驅動利用多年來在編寫C庫上所做的工作

5.3.3.資料庫供應商必須為驅動提供與平台相關的原生庫，Java程式也必須設定環境變量才能使用該庫

5.3.4.性能往往非常好

5.4.4型驅動

5.4.1.純Java驅動

5.4.2.實作了資料庫供應商為通路資料庫定義的線路協定

5.4.3.性能通常和2型驅動一樣好

5.4.4.最容易使用

5.5.推薦使用

6.預處理語句

6.1.不是Statement進行JDBC調用

6.1.1.語句隻使用一次

6.1.1.1.最好使用Statement正常語句

6.2.使用PreparedStatement場景

6.2.1.重用

6.2.2.包含很多JDBC調用的批處理程式

6.2.3.在其生命周期中會服務大量請求的伺服器

6.3.具有安全性和程式設計的優勢

6.4.會消耗大量的堆空間

6.4.1.避免因池化太多非常大的對象而産生GC問題

7.預處理語句被池化

7.1.重用PreparedStatement對象關鍵點

7.1.1.JDBC連接配接池

7.1.2.JDBC驅動配置

7.2.必須在每個連接配接的基礎上進行池化

7.2.1.大多數JDBC驅動和資料架構可以自動地做到這一點

7.2.2.確定JDBC驅動和資料架構隻有一個在管理預處理語句池是非常重要的

7.2.3.預期JDBC驅動能夠更好地池化語句

7.2.3.1.驅動是針對特定資料庫的

7.2.3.2.比更通用的應用程式伺服器代碼更好

7.3.連接配接池的大小很重要

7.3.1.會緩存預處理語句

7.3.1.1.語句緩存

7.3.1.2.會消耗大量的堆空間

7.4.管理語句池

7.4.1.ConnectionPoolDataSource類的setMaxStatements()方法可以啟用或禁用語句池

7.4.1.1.setMaxStatements()方法的值為0，語句池就會被禁用

7.4.2.配置JDBC驅動來建立和管理語句池

7.4.2.1.查閱該驅動的文檔

7.4.2.2.設定驅動，将maxStatements屬性設定為所需的值（語句池的大小）

7.4.2.3.額外的設定

7.4.2.3.1.Oracle設定确定是使用隐式語句池還是顯式語句池

7.4.2.3.2.MySQL設定另一個屬性來啟用語句池

7.4.3.在應用程式代碼中建立和管理語句池

8.事務

8.1.應用程式對正确性的要求最終決定了事務的處理方式

8.1.1.不要讓對性能的渴望超過應用程式的正确性

8.2.性能損失

8.2.1.資料庫事務的建立和送出需要時間

8.2.1.1.確定資料庫的更改完全存儲到磁盤上

8.2.1.2.要確定資料庫事務日志是一緻的

8.2.2.事務通常會獲得一組特定資料的鎖

8.3.事務的開始和結束都基于Connection對象的使用方式

8.3.1.通過setAutoCommit()方法設定連接配接有一個自動送出模式

8.4.事務送出成本很高

8.4.1.一個目标是在一個事務中執行盡可能多的工作

8.4.2.另一個目标執行時間應該盡可能短

8.4.3.沖突

8.5.鎖可以保護資料的完整性

8.6.事務隔離模式

8.6.1.TRANSACTION_SERIALIZABLE

8.6.1.1.序列化事務

8.6.1.2.成本最高

8.6.1.3.在事務進行期間，事務通路的所有資料都被鎖定

8.6.1.4.适用于通過主鍵通路的資料和通過WHERE子句通路的資料

8.6.1.5.在使用WHERE子句的時候，表會被鎖定，這樣在事務進行期間就不能添加滿足該子句的新資料

8.6.1.6.每次查詢時看到的資料就都是一樣的

8.6.2.TRANSACTION_REPEATABLE_READ

8.6.2.1.重複讀

8.6.2.2.在事務進行期間，被通路的所有資料都被鎖定

8.6.2.3.其他事務可以在任何時候向表中插入新的資料

8.6.2.4.幻讀（phantom read）

8.6.2.4.1.一個事務重新執行使用某個WHERE子句的查詢時，第二次可能會得到不同的資料

8.6.2.5.MySQL預設

8.6.2.6.Oracle不支援

8.6.3.TRANSACTION_READ_COMMITTED

8.6.3.1.不可重複讀

8.6.3.2.鎖定事務進行期間被寫入的資料

8.6.3.3.在事務進行期間，某一時刻讀取的資料可能和另一時刻讀取的資料不同

8.6.3.4.Oracle預設

8.6.3.5.IBM Db2預設

8.6.4.TRANSACTION_READ_UNCOMMITTED

8.6.4.1.成本最低

8.6.4.1.1.不涉及鎖

8.6.4.2.髒讀（dirty read）

8.6.4.2.1.一個事務可以讀取在另一個事務中寫入（但未送出）的資料

8.6.4.2.2.第一個事務可能會復原（寫入操作沒有實際發生），是以第二個事務會在錯誤的資料上操作

8.6.4.3.Oracle不支援

8.6.5.TRANSACTION_NONE

8.6.5.1.JDBC規範定義了第5種事務隔離模式

8.6.6.setTransactionIsolation()方法

8.6.6.1.給資料庫提供必要的事務隔離級别

8.6.6.2.如果資料庫不支援給定的級别

8.6.6.2.1.JDBC驅動會抛出異常

8.6.6.2.2.自動将隔離級别設定為它支援的下一個更嚴格的級别

8.6.7.悲觀鎖（pessimistic locking）

8.6.8.樂觀鎖（optimistic locking）

8.6.8.1.資料通路不存在競争，采用樂觀鎖會顯著提升性能

8.6.8.2.當兩個資料源之間發生競争的機率很小時，樂觀鎖的效果最好

8.7.結果集

8.7.1.設定JDBC驅動一次傳輸的資料行數

8.7.1.1.可以使用PreparedStatement對象上的setFetchSize()方法

8.7.1.2.預設值因JDBC驅動的不同而不同

8.7.2.處理大量查詢資料的應用程式時應該考慮更改資料的提取大小

8.7.3.權衡

8.7.3.1.在應用程式中加載太多資料（給垃圾回收器增加壓力）

8.7.3.2.為了檢索一組資料而頻繁調用資料庫