本文分析了 java 訪問數據庫的瓶頸問題，并給出了相應的解決辦法。

速度瓶頸問題的提出
在企業級的Java應用中，訪問數據庫是一個必備的環節。數據庫作為數據資源的集散地，往往位于企業級軟件體系的后方，供前方的應用程序訪問。在Java技術的體系中，應用程序是通過JDBC（Java Database Connectivity）接口來訪問數據庫的，JDBC支持"建立連接、SQL語句查詢、處理結果"等基本功能。在應用JDBC接口訪問數據庫的過程中，只要根據規范來操作，這些功能的實現不會出差錯。但是，有些時候進行數據查詢的效率著實讓開發人員懊惱不已，明明根據規范編寫的程序，卻得不到預期的運行效果，造成了整個軟件的執行效率不高。

起初，我們把問題歸結于Java字節碼加載和執行速度的緩慢，緊接著硬件的功能普遍得到了增強，證實這樣的想法些許是錯誤的，還沒有抓到真正的根本原因。本文將逐步解剖JDBC訪問數據庫的機制，深層分析造成這種速度瓶頸問題的原因，并提出在現有的Java技術框架下解決這個速度瓶頸問題的思路和方法。

JDBC訪問數據庫的機制

圖1和圖2描述了Java應用程序通過JDBC接口訪問數據庫的4種驅動模式，也就是底層實現JDBC接口的模式。對于這些模式，我們逐一介紹：

模式4：圖1左邊的分支稱為模式4，它一般是數據庫廠商才能實現的純Java的基于本地協議的驅動，直接調用DBMS（數據庫治理系統）使用的網絡協議，對于企業內部互聯網來說，是一個實用的解決方案。

模式3：圖1右邊的分支稱為模式3，它同樣是一個純Java驅動，不同于模式4的是基于網絡協議。它的機制是將JDBC調用轉換為中間網絡協議，然后轉換為DBMS協議。中間網絡協議層起到一個讀取數據庫的中間件的作用，能夠連接許多類型的數據庫，因而是最靈活的JDBC模式。這種模式的產品比較適用于企業內部互聯網，如若支持國際互聯網，還需添加對安全、穿過防火墻訪問等的支持。

模式1：圖2左邊的分支稱為模式1，即通常由Sun公司提供的JDBC-ODBC橋接器。它提供了經由一種或多種ODBC驅動進行訪問的JDBC接口，而ODBC驅動，在很多情況下也即數據庫的客戶端，必須加載到客戶機。因而，它適用于下載和自動安裝Java程序不重要、實驗用途或者沒有其它JDBC驅動可用的情況下。

模式2：圖2右邊的分支成為模式2，類似于JDBC-ODBC橋接器，需要加載到客戶機，卻是一個部分用Java實現的驅動接口。它將JDBC調用轉換為對數據庫（Oracle、Sybase、Informix、DB2等）客戶端接口的調用。

不同模式的JDBC接口的選擇
以上闡述的JDBC接口的模式不同，讓我們可以把JDBC接口按照實現的模式分為四類。有些同仁可能有這樣的體會，選擇不同的JDBC接口會有不同的訪問速度，為何會出現這樣的情況？這個問題的答案是，不同的應用需要不同模式的JDBC接口，因而我們在面對一個應用時，要慎重選擇JDBC接口。

通常的DBMS都支持微軟提出的ODBC規范，因而模式1可當作您在設計和實現軟件時的選擇，它易于配置的特性能夠讓你把選擇JDBC等煩惱的問題暫且拋在一邊，讓自己的Java程序能夠及早地正常工作起來。

一般說來，商業DBMS的提供者往往會為自己的數據庫提供一個JDBC接口，應用的是模式4。這種模式的優勢在于和數據庫本身結合比較緊密，而且是純Java的實現，在企業級的軟件應用中，應該是首選。例如，對于Oracle數據庫來說，有Oracle、SilverStream、DataDirect等公司提供這種類型的驅動，其性能往往被評價為最高效的、最可靠的驅動程序。但偶然也有比較麻煩的情況，例如微軟就不會提供MS SQL的JDBC接口，這時就需要到Sun的網站（ http://industry.java.sun.com/PRodUCts/jdbc/drivers）查找相關的模式4驅動，上面提到的DataDirect公司（ http://www.datadirect-technologies.com/jdbc/jdbc.asp）就提供了支持MS SQL的模式4驅動，只是你需要支付750$購買這個JDBC驅動。