轉自：

https://juejin.im/entry/5905ac37a22b9d0065e1199c

基於關係型資料庫的水平擴充套件方案有很多開源的解決方案，但成熟穩定的產品鳳毛麟角。噹噹自研的資料庫中間層 Sharding-JDBC 在公司內部已廣泛使用，並在開源社群推廣且初見成果。目前的 Sharding-JDBC 已經歷從初出茅廬到穩定執行，再到變革的關鍵點。

Sharding-JDBC 採用在 JDBC 協議層擴充套件分庫分表，是一個以 jar 形式提供服務的輕量級元件，其核心思路是小而美地完成最核心的事情。

對於這麼優秀的一個專案， 在高手問答第 144 期中，我們策劃了 “ 輕量級資料庫中間層 Sharding-JDBC 深度解析 ” 的主題，並邀請了

本文整理了此次高手問答中一些精彩的問答。

對於這樣一個專案，想必大家都會關心它的開發初衷和適用場景等相關問題。下面先來看看張亮老師對於這些問題的解答。

Q：Sharding-JDBC 的設計初衷是什麼？旨在解決什麼場景的問題？

Sharding-JDBC 的設計初衷是想提供一個數據庫中間層，用於透明的處理分庫分表，而無需業務開發人員在業務程式碼中根據分片鍵生成 SQL。

第一版的分庫分表並不是現有的 Sharding-JDBC，而是噹噹的一個內部框架 ddframe 的資料庫模組，dd-rdb 的其中一項功能就是分庫，沒有分表功能，當時只是做了簡單的 SQL 解析。後來隨著 ddframe 被各個團隊採用，只分庫的需求漸漸不夠用了，而 dd-rdb 裡面有大量的資料庫 ORM 相關的東西，為了使分庫分表這一核心需求更加純粹，我們才將其中的分片的部分單獨提煉出來並命名為 Sharding-JDBC，用於在 Java 的 JDBC 層面提供一層驅動，無縫的處理這方面的需求。

Q：Sharding-JDBC 適用於哪些場景，不適用於哪些場景？是否有效能評估？

對於關係型資料庫資料量很大的情況，需要進行水平拆庫和拆表，這種場景很適合使用 Sharding-JDBC。

舉例說明：假設有一億資料的使用者庫，放在 MySQL 資料庫裡查詢效能會比較低，而採用水平拆庫，將其分為 10 個庫，根據使用者的 ID 模 10，這樣資料就能比較平均的分在 10 個庫中，每個庫只有 1000w 記錄，查詢效能會大大提升。分片策略型別非常多，大致分為 Hash + Mod、Range、Tag 等。

Sharding-JDBC 還提供了讀寫分離的能力，用於減輕寫庫的壓力。

此外，Sharding-JDBC 可以用在 JPA 場景中，如 JPA、Hibernate、Mybatis，Spring JDBC Template 等任何 Java 的 ORM 框架。

Java 的 ORM 框架也都是採用 JDBC 與資料庫互動。這也是我們選擇在 JDBC 層，而非選擇一個 ORM 框架進行開發的原因。我們希望 Sharding-JDBC 可以儘量的相容所有的 Java 資料庫訪問層，並且無縫的接入業務應用。

不合適的場景主要是兩方面：

1. 不適合 OLAP 的場景。雖然 Sharding-JDBC 也能做聚合分組查詢，但大量的 OLAP 場景，仍然會比較慢，而且複雜的 SQL（如子查詢等）目前還沒有支援。這種查詢不太適合大資料和高併發的網際網路 online 資料庫，建議使用合理的 OLTP 查詢。
2. 不適合事務強一致的要求。目前 Sharding-JDBC 的事務支援兩種，一種是弱 XA，另一種是柔性事務（BASE）。因為 XA 的兩階段或三階段提交其效能較低，因此網際網路公司基本不會採用。而無論是弱 XA 還是柔性事務，都無法保證事務在任意時間段完全保證一致，其中柔性事務能保證資料的最終一致性，但達到最終一致性的時間仍然不可控。因此對於對跨庫事務強一致要求很高的場景，需要從設計方面去考慮資料庫 schema 的合理性。

對於 JTA 事務，目前 Shariding-JDBC 沒有實現 JTA 的標準。而且由於在網際網路場景下使用 JTA 比較少見，因此暫時不支援 JIA 事務。

在 osgit 上有效能測試文件。單庫的場景下，由於需要進行 SQL 解析以及路由，器效能損失是 0.02%。雙庫的場景下，採用了分散式的方式存取資料，效能提升越 94%。

那麼對於同類的專案，老師又是如何看待的呢？

Q：Sharding-JDBC 和其他同類產品有什麼區別？能不能整合到 SparkSQL 或者 Hive？

目前和 Sharding-JDBC 這種基於 JDBC 層架構類似的，據我所知只有 TDDL，而 TDDL 並未將分庫分表這塊開源。基於 JDBC 層進行分片的好處是輕量、簡單、相容性好以及無需額外的運維工作。缺點是無法跨語言，目前僅支援 Java。

現在暫時未考慮整合 SparkSQL 或者 Hive。因為 Sharding-JDBC 的定位還是關係型資料庫中間層，為了穩定性的考慮，不會改變資料庫的儲存引擎。未來我們會做基於 Proxy 版本的 Sharding-JDBC-Server，會漸漸的考慮將 Spark 等大資料的查詢方式引入進來。

Q：Sharding-JDBC 與 Mycat 有一定的相似性，區別點在於對於 SQL 語句的自解析上，是否可以這麼理解？

從設計理念上看確實有一定的相似性。主要流程都是 SQL 解析 -> SQL 改寫 -> SQL 路由 -> SQL 執行 -> 結果歸併。但架構設計上是不同的。Mycat 是基於 Proxy，它複寫了 MySQL 協議，將 Mycat Server 偽裝成一個 MySQL 資料庫，而 Sharding-JDBC 是基於 JDBC 介面的擴充套件，是以 jar 包的形式提供輕量級服務的。

SQL 解析這塊，現在的 Shariding-JDBC 和 Mycat 也比較相似，都是使用 Druid 作為 SQL 解析的基礎類庫。但 Sharding-JDBC 正在重寫 SQL 解析這塊，是去掉 Duird 的完全自研版本。不可否認 Druid 是一個優秀的連線池，而且 SQL 解析這塊做得也很強，但它畢竟不是一個專門為了 Sharding 而做的 SQL 解析器，它的大致解析流程是 Lexer -> Parser -> AST -> Vistor，使用者需要實現它的 Vistor 介面，將自己的業務邏輯在 Vistor 中實現，因此需要通過 Vistor 再生成 SharidingContext，而抽象語法樹 AST，也需要對 SQL 完全理解。Sharding-JDBC 自研的 SQL 解析器，對於 Sharding 不相關的關鍵詞采用跳過的方法，整體解析流程簡化為 Lexer -> Parser -> SharidingContext，在效能以及實現複雜度上都有所突破。

接下來老師和大家分享了一些關於 Sharding-JDBC 功能的問題

Q：Sharding-JDBC 是否支援讀寫分離？

Sharding-JDBC 從 1.3.0 開始支援讀寫分離。其功能包括：

1. 根據配置區分寫庫和多個讀庫，目前暫時只有輪訓策略選取讀庫，可以配合分庫分表使用。
2. 通過 Hint 強制指定某次查詢走寫庫。
3. 如果在同一執行緒且同一資料庫連線中有發現 DML 語句，則該 DML 之後的查詢都從寫庫查詢，DML 之前的 DQL 語句不受影響，仍然查詢讀庫。其目的是保持同一使用者執行緒的資料一致性。

但限於 Sharding-JDBC 本身設計的考慮，資料庫層面的主從切換以及主從資料同步，Sharding-JDBC 並不負責。Sharding-JDBC 定位仍然是輕量級的增強版資料庫驅動。因此由於主庫和從庫同步延遲導致的資料不一致，並不是 Sharding-JDBC 的處理範疇。

另外由於 Sharding-JDBC 本身是分庫分表中介軟體，讀寫分離也是後加入的功能，因此可以支援分庫分表+讀寫分離，但是僅讀寫分離目前還不容易配置，未來也會將讀寫分離提煉出來作為獨立的 API 使用。

Q：在現有的系統架構的基礎上，Sharding-JDBC 能否與第三方資料庫連線池（如：C3P0，Druid 等）整合，實現分庫分表+讀寫分離？

是的，可以支援。Shariding-JDBC 本意就是隻做分片 + 讀寫分離，連線池應該交由連線池去處理，各做各的互不影響。

Q：分庫分表使用 like 查詢，是否能查詢出來？效能如何？會去查詢所有的庫和表嗎？

• 分庫分表使用 like 查詢是有限制的。目前 Shariding-JDBC 不支援 like 語句中包含分片鍵，但不包含分片鍵的 like 語句可以正確執行。
• 至於 like 效能問題，是與資料庫相關的，Shariding-JDBC 僅僅是解析 SQL 以及路由至正確的資料來源而已。
• 是否會查詢所有的庫和表是根據分片鍵決定的，如果 SQL 中不包括分片鍵，就會查詢所有庫和表，這個和是否有 like 沒有關係。

Q：Sharding-JDBC 是否有完善的管理配置介面？

目前 Sharding-JDBC 還沒來得及做配置介面。目前主要集中於以 jar 包的形式提供服務，和業務應用一起釋出，旨在簡化開發，對 DBA 無影響，因此 DBA 看到的還是分庫後的零散的資料庫。

未來會做配置中心，用於動態的修改分片資料來源，也會配套的提供管理介面。未來還會將資料庫的 Metadata 統一管理起來，為 DBA 提供更加友好的服務。

Q：Sharding-JDBC 如何強制查詢走主庫？

大致使用方式如下：

HintManager hintManager = HintManager.getInstance();
hintManager.setMasterRouteOnly();
// 繼續JDBC操作

還有一些與 Sharding-JDBC 相關的問題，張亮老師也進行了詳盡的解答

Q：Sharding-JDBC 是如何解決系統魯棒性的問題的？我們的後臺對服務的可靠性要求比較高，目前還在考慮異地災備的情況。如使用 Sharding-JDBC 的話，碎片化的庫表結構是否會增加運維難度？

因為 Sharding-JDBC 是一個 jar，它與業務應用的生命週期是一致的，同生同死。因此只要解決好使用 Sharding-JDBC 的業務系統的魯棒性就可以了。

碎片化庫表的問題，即使不用 Shariding-JDBC 分庫分表，也會同樣存在的，Shariding-JDBC 確實沒處理這塊，不過也不會更加惡化。

等核心穩定後，未來會考慮為 DBA 做運維工具。

Q：請問 Sharding-JDBC 自研的 SQL 解析器開源否？效能能否有大的提升？另外，現在噹噹的業務中，資料庫的分庫分表遷移可否自動化？

Sharding-JDBC 自研的 parser 是開源的，目前在 parser 這個分支，但是還未做完，仍然在快速的迭代中。

SQL 解析原理和 Druid 基本相同，但是簡化了一些流程。Duird 的初衷是對 SQL 進行監控、分析以及規範化，因此它的 SQL 解析場景需要對 SQL 進行完全的理解。採用 Druid 的作為基礎解析器的 Sharding-JDBC 解析流程為：（Lexer -> Parser -> AST -> Vistor） -> SharidingContext，其中括號內是 Duird 框架的流程，無法修改。而 Sharding-JDBC 僅需理解與 Sharding 相關的關鍵字，無關內容則採取跳過的方式，因此將直接生成分片上下文，無需再通過抽象語法樹的訪問器再獲取。

New Parser 的解析流程簡化為：Lexer -> Parser -> SharidingContext。因此在效能以及實現複雜度上都有所突破。具體的效能測試報告目前還未做，會隨著 New Parser 分支完全一起釋出。

關於分庫分表自動遷移的事，噹噹還沒有做到自動化。由於資料遷移更加貼近於資料庫運維工具，和 JDBC關係不大，因此 Shariding-JDBC 也暫時未將資料遷移納入範圍。

關於 Sharding-JDBC 未來的規劃，張亮老師也和我們分享了很多幹貨

Q：Sharding-JDBC 下一步規劃是什麼？

Sharding-JDBC 目前正在進行 SQL Parser 部分的重寫。之前的 Sharding-JDBC 使用 Duird 作為 SQL 解析的基礎工具，但基於各方面的考慮，我們決定採用自研的方式解析 SQL，能進一步的提升效能和 Sharding 的準確性以及相容性。

New SQL Parser 完成之後，我們會著重處理之前沒有完成的柔性事務 TCC 部分，更多型別 SQL 的支援以及配置動態化。

這些做完之後會考慮將 Sharding-JDBC 分為 Sharding-Driver 以及 Sharding-JDBC-Server 兩個版本，用於滿足不同使用者的需要。Sharding-JDBC-Driver 會更加輕量級，而 Sharding-JDBC-Server 會以 Proxy 的形式提供服務，能更好的處理資料遷移，事務以及 OLAP 等需求。

Shariding-JDBC 的核心應該就是 JDBC 驅動的增強，以 jar 形式提供輕量級的服務。大體上看，Sharding-JDBC 的生態應該大致分為 3 個環路：

• 一環是 JDBC 相關的核心功能，包括分庫分表、讀寫分離、分散式主鍵等。這個是小而美的核心部分。
• 二環是和資料庫相關，但不屬於 JDBC 範疇的，將以外掛的形式提供，包括柔性事務、資料庫的 HA、資料庫 Metadata 管理、配置動態化等。
• 三環是業務或使用友好度相關的，包括多租戶、賬戶安全、Spring 自定義名稱空間、Yaml 配置等。

有很多朋友提到關於對其他語言的支援，因為 Shariding-JDBC 是基於 Java 提供的 JDBC 規範的介面所開發，因此目前暫時不支援 Python、Node.js 等。

但其核心的解析、路由、結果歸併等功能模組和基於 Proxy 版本開發幾乎是一致的。因此，未來我們有打算提供 Shariding-JDBC-Server 版本，將會支援全語言。

有朋友看到我們在考慮開發 Sharding-JDBC-Server，以為目前的 Sharding-JDBC 模式遇到了某些不可解決的問題。其實 Shariding-JDBC 以當前的定位來說，沒有遇到不可解決的問題，但如果想做的更多（前面提到的資料遷移，分散式事務，元資料管理等），則需要向 Proxy 的方式靠攏。Shariding-JDBC 想提供兩種不同的使用方式，給使用者更自由的選擇。

還有就是對 SQL 語句的支援。由於時間和精力有限，目前無法做到全 SQL 的相容。我們現階段的目標是儘量支援 OLTP 最常用的 80% 的 SQL。目前支援聚合、分組、排序等查詢。暫時不支援 distinct，對 or 的支援也不是特別完善，但是 distinct 和 group by 可以互換，or 也可以用 in 代替。因此絕大部分 SQL 經過修改是可以使用的。

有朋友提到，既然 distinct 和 group by 可以互換，or 可以用 in 代替，那麼是不是可以考慮直接在 SQL 解析的時候自動切換？

對於這個問題，雖然這樣做在技術上是可行的，但是設計上來說還有待商榷。

如果已經做了 distinct 和 or 的解析，其實完全沒有必要改寫 SQL，直接支援就可以了。而改寫 SQL，對於 DBA 的除錯就比較痛苦，因此我們希望做到儘量不修改 SQL，僅修改必要的部分，如：分表的名稱、avg 轉化為 count 和 sum、limit 的 offset 和 rowCount。

對於過於複雜的 SQL，如子查詢等，不一定適合在大資料量的分片資料庫中使用，也許需要重新梳理。

未來我們也會對 SQL 相容性這塊持續進行提升。

目前 Sharding-JDBC 僅支援 MySQL，對其他資料庫的支援（比如 Oracle）也正在進行。現在 New SQL Parser 正在進行中。計劃在這個版本釋出對 Oracle、PG 以及 SQLServer 的支援。對於 Oracle 以及 SQLServer 主要的支援在於特殊關鍵詞識別和分頁。

New SQL Parser 確實工作量比較大，雖然目前整體程式碼已經梳理得差不多了，但想穩定的提供服務還需要一些時間。預計 4 月份提供 snapshot，6 月份提供穩定版。

New SQL Parser 在 Git 的 parser 分支援續更新中，歡迎繼續關注。

還和大家分享了很多資料庫相關的使用經驗和心得

Q：現在用著自己寫的 Sharding，不過在解析語句這塊比較尷尬，有些語句解析不來，所以自己封裝 jsqlparser，Druid，自寫正則三個方法來取表名，老師有什麼建議？

jsqlparser 用的是 JavaCC 的方式解析 SQL，相對於 Druid 來說，效能比較低。正則解析的話，效能應該會更低，而且這兩種方式都比較難調優。

Druid 採用的詞法和語法分析的方式解析 SQL，編碼工作量大，但效能會提升很多。Druid 的 SQL 解析器對於開發者而言稍微有些不易上手。Shariding-JDBC 採用與 Druid 相同的 SQL 解析方式，但為 Sharding 做了優化。

只是獲取表名的話，jsqlparser 和 Duird 都沒問題，如果考慮效能問題，還是建議用 Druid 或者參考下 Sharing-JDBC 的做法。

Q：對於分散式事務這塊，有什麼實踐經驗分享嗎？

分散式事務這塊，我們認為 XA 多階段提交的方式，雖然對分散式資料的完整性有比較好的保障，但會極大的降影響應用效能，並未考慮採用。我們採用的是兩種方式，一種稱之為弱 XA，另一種是柔性事務，即 BASE。

弱 XA 就是分庫之後的資料庫各自負責自己事務的提交和回滾，沒有統一的排程器集中處理。這樣做的好處是天然就支援，對效能也沒有影響。但一旦出問題，比如兩個庫的資料都需要提交，一個提交成功，另一個提交時斷網導致失敗，則會發生資料不一致的問題，而且這種資料不一致是永久存在的。

柔性事務是對弱 XA 的有效補充。柔性事務型別很多。

Sharding-JDBC 主要實現的是最大努力送達型。即認為事務經過反覆嘗試一定能夠成功。如果每次事務執行失敗，則記錄至事務庫，並通過非同步的手段不斷的嘗試，直至事務成功（可以設定嘗試次數，如果嘗試太多仍然失敗則入庫並需要人工干預）。在嘗試的途中，資料會有一定時間的不一致，但最終是一致的。通過這種手段可以在效能不受影響的情況下犧牲強一致性，達到資料的最終一致性。最大努力送達型事務的缺點是假定事務一定是成功的，無法回滾，因此不夠靈活。

還有一種柔性事務型別是 TCC，即 Try Confirm Cancel。可以通過事務管理器控制事務的提交或回滾，更加接近原生事務，但仍然是最終一致性。其缺點是需要業務程式碼自行實現 Try Confirm Cancel 的介面，對現有業務帶來一定衝擊。未來 Sharding-JDBC 會帶來對 TCC 的支援。

還有一些其他的分散式事務，如 Google 提出的 F1 等，由於 Shariding-JDBC 仍然使用資料庫的原有儲存引擎，並未改變，因此暫時不考慮對此型別事務的支援。

Q：請問何時需要分表？目前我們都是按照業務分庫。

分庫分表分為水平拆分和垂直拆分。按照業務分庫或分表屬於垂直拆分。水平拆分是將同樣的庫或表按照一定的分片規則拆成多個。

分庫和分表都可以有效的處理由於資料量大而導致的查詢效能下降的問題。分庫還可以緩解高併發對資料庫帶來的壓力，但僅分表可以使用本地事務代替分散式事務。因此分庫和分表的合理使用是需要根據業務場景來決定的。

Sharding-JDBC 作為開發的基礎類庫，支援分庫和分表，將選擇的餘地留給業務開發的工程師。

Q：請教一下，根據主鍵分片，以使用者名稱登入，如何知道使用者落在哪個分片上？

如果使用者名稱是主鍵，則可以直接根據您定義的分片策略計算，算出該使用者最終落在哪個庫的哪張表上。

如果使用者名稱不是主鍵，則必須通過全路由查詢，一個一個的找，直到找到為止。

張亮老師還和大家暢談了很多其他關於資料庫的問題

Q：我有一個很大的問題，就是如何判斷自己需要搞魔改還是換資料庫呢？MySQL 各種魔改的成本恐怕未必比買高階資料庫便宜吧。特別是現在資料庫很多都有云服務可以選擇，買個 Oracle 或者微軟的雲服務資料庫，入門成本現在應該可以被中小企業接受了吧。

這個問題比較大，需要從整體的角度來討論一下。

MySQL + 開源分片中介軟體是公司將技術核心抓在了自己的手裡，網際網路公司大多願意採用。這個不僅是眼前的經濟成本問題，還包括了技術問題解決成本、對業務發生變化時對技術的控制能力等。比較成熟的公司都會沉澱出適合自己的中介軟體架構，以及各種監控、治理等輔助系統。

NoSQL 也是一種選擇，但它們的定位是關係型資料庫的有益補充，並不是要完全替換掉關係型資料庫，因此，關係型資料庫 + 分片仍然有其存在價值。

對於 Oracle，我的看法是重要的業務資料可以考慮，而一些周邊資料，就沒什麼必要。當然如果公司不差錢，定位又非技術導向，而是純業務導向的話，完全依賴 Oracle 也是可以的。只不過 Oracle 不能滿足網際網路的全部場景。各種雲資料庫和 Oracle 差不多，公司對自我的定位很重要。如果有核心業務，完全可以把技術全包出去。

個人理解，當業務量較小或適中的情況下，採用 Oracle 和雲資料庫是合理的選擇。而在公司的業務爆炸式增長的大型網際網路公司，這些方案未可行，因為獨角獸級別的公司遇到業務場景基本都是獨一無二的，其解決方案並不是第三方功能能夠直接給予的。成長到一定程度的公司大多會選擇自研 + 開源的組合，保證其技術的適應度以及和業務的匹配度。

Q：所以說選型其實是針對 OLTP 業務模型和資料量的變化作為主要考慮指標？在初期未必有足夠的技術和資金的時候，選擇免費的 MySQL 先用起來。然後等活下來有能力做大，資料也暴漲了，這時候就招人來魔改，或者選擇已有魔改方案。傳統商業資料庫集中在財務等關鍵地方，或者 OLAP 這種 MySQL “草雞”的領域（也可能完全不用資料庫選擇大資料產品）。不知道我理解得是否正確。

是的，正確。

簡單說，剛起步用 MySQL；有錢並且業務量適中用 Oracle，核心業務用 Oracle，非核心業務用雲資料庫；資金不充足業務量較大用 MySQL + 開源中間層；業務量超大隻能自研。

大資料和關係型資料庫不是一個方向，主要用於儲存其他型別資料了，訂單、交易等資料一般不會放大資料，更適合日誌，瀏覽記錄等。

Q：另外在選型上，我還想提一下 PG 這個資料庫。業內選擇 MySQL 比較多，PG 比較少。是不是就是因為 PG 在大規模叢集魔改方面一直沒有成功案例的關係？起碼自從谷歌魔改 MySQL 開始，我們聽說了太多的案例。PG就好像沒聽說過了。

用了 MySQL，哪怕有各種糟糕，但是因為有各種成功案例和各種第三方開源魔改叢集方案，起碼我知道可以做得夠大。但是 PG 雖然特性上遠遠強過 MySQL，但是因為本身不像 MySQL 那麼靈活，所以採用的反而少。有錢的買商業，沒錢的 MySQL+Hadoop。

Sharding-JDBC 的服務物件是任何關係型資料庫，無論是 MySQL 還是 PG。

不過針對這個問題可以再大致聊一下。很多公司的技術選型在於平衡，尤其是資料庫選型這塊。不一定 MySQL 就是最好的資料庫，某些方面 PG 確實要更好，但 MySQL 是在各個方面受認可最多的資料庫。比如周邊的 MHA 套件、開發和 DBA 對資料庫的熟悉程度等。因此，即使是 MySQL 的分支版本 MariaDB 或 Percona，無論功能效能再怎麼提升、引擎再怎麼變化，其總體的認可度也還是不如 MySQL 的。

Q：有一個問題一直很疑惑，目前分庫分表的中介軟體有兩種思想，分別是：

1. 類似 Sharding-JDBC 及 TDDL 的增強版 JDBC 驅動思想
2. 類似 Mycat 增加中間層，然後在中間層進行分庫分表思想

我想問的是，這兩種思想都有什麼優勢和劣勢呢，大公司的主流選型又是哪種？

兩種方式各有優缺點。

JDBC 驅動版的優點：

1. 輕量，範圍更加容易界定，只是 JDBC 增強，不包括 HA、事務以及資料庫元資料管理
2. 開發的工作量較小，無需關注 nio，各個資料庫協議等
3. 運維無需改動，無需關注中介軟體本身的 HA
4. 效能高，JDBC 直連資料庫，無需二次轉發
5. 可支援各種基於 JDBC 協議的資料庫，如：MySQL，Oralce，SQLServer

Proxy 版的優點：

1. 可以負責更多的內容，將資料遷移，分散式事務等納入 Proxy 的範疇
2. 更有效的管理資料庫的連線
3. 整合大資料思路，將 OLTP 和 OLAP 分離處理

因此兩種方式互相可以互補，建議使用 Java 的團隊，且僅 OLTP 的網際網路前端操作。有可能會使用多種資料庫的情況，可以選擇 JDBC 層的中介軟體；如果需要 OLAP 和 OLTP 混合，加以重量級的操作，如資料遷移，分散式事務等，可以考慮 Proxy 層的中介軟體。但目前開源的資料遷移和分散式事務的完善解決方案還不常見。NewSQL 這種改變資料庫引擎的方式就不在這裡討論了。