大規模Web應用系統, 幾乎都會遇到資料庫瓶頸問題. 在早期, 通過資料庫配置優化, 表優化, 索引優化等軟體方法, 可以解決一些問題. 馬上, 資料庫瓶頸迫使不得不把MySQL和Apache單獨部署到不同的機器, 形成Web伺服器(Web Server)和資料庫伺服器(DB Server)的物理分離, 這樣就能解決大部分的問題. 但是, 在繼續發展時, 一臺Web伺服器和一臺資料庫伺服器也不能滿足高併發的訪問量了.

這時, 問題首先是計算能力的問題, 也就是硬體不夠用的問題. 所以, 需要上多臺Web伺服器和多臺資料庫伺服器.

有時候, 網站可以縱向切分, 這樣, 任何兩臺伺服器(一臺Web Server + 一臺DB Server)單獨配置, 便能執行一個應用. 比如某兩臺執行著論壇程式, 某兩臺執行著新聞程式.

很多情況下, 並不能縱向切分, 每一臺的Web Server的角色和功能都是一樣的, 沒有差別, DB Server也是一樣. 理想的情況下, 同種壓力的SQL語句平均分佈到每一臺DB Server, 那就能解決高併發資料庫請求問題了

dbproxy的作用便是如此: 合理地分配資料庫請求給所有的DB Server, 使得在請求的數量等於或者小於所有DB Server的計算能力總和時, 服務能夠正常執行.

第一種方式的dbproxy: Web Server上的資料庫客戶端(如PHP指令碼)擁有選擇DB Server的智慧.

這種方式實現簡單, 完全用Web指令碼實現, 指令碼自己判斷應該連線其中的一臺或者幾臺DB Server, 請決定把SQL請求發給誰. 這種方式因為效能問題, 所以應用不是很廣.

第二種方式的dbproxy: SQL代理程序

類似HTTP代理伺服器, 這種方式的dbproxy獨立執行, 所以客戶端請求將不再直接和DB Server連線, 而是通過它中轉. 這樣的dbproxy, 首先要擁有解析協議(也即SQL)的能力, 這也帶來一個特點, dbproxy可以與後端的MySQL連線, 但卻接收前端(如PHP指令碼)發來的Oracle資料庫的SQL請求.

當然, dbproxy的主要功能還是在SQL分發方面. 另外, 還可以在dbproxy上面做與業務更接近的快取, 相比資料庫的底層快取很多時候更有效.