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. 為了檢索一組資料而頻繁呼叫資料庫
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/545390.html
標籤：其他