一般對於業務記錄類隨時間會不斷增加的資料，當資料量增加到一定量（一般認為整型值為主的表達到千萬級，字串為主的表達到五百萬）的時候，效能將遇到瓶頸，同時調整表結構也會變得非常困難。為了避免生產遇到這樣的問題，在做系統設計時需要預估可能產生的資料量：預估記錄主體個數*預估記錄主體產生的記錄數（e.g.使用者訂單表預估資料量=預估使用者數*單使用者產生訂單數），預估達到一定量時，就不得不考慮分庫分表了，目前國內比較成熟的開源資料庫中介軟體有sharding-jdbc、mycat；而drds是阿里雲最近推出的商業產品，考慮到大部分公司都在使用阿里雲，做一個全家桶，也是一個不錯的選擇。接下來將對這三款產品的優缺點及適用場景做以介紹。

        可以看出sharding-jdbc作為一個元件整合在應用內，而mycat則作為一個獨立的應用需要單獨部署，drds則是阿里雲的一個獨立產品，不過需要結合rds一起使用。從架構上看sharding-jdbc更符合分散式架構的設計，直連資料庫，沒有中間應用，理論效能是最高的（實際效能需要結合具體的程式碼實現，理論效能可以理解為上限，通過不斷優化程式碼實現，逐漸接近理論效能）。同時缺點也很明顯，由於作為元件存在，需要整合在應用內，意味著作為使用方，必須要整合到程式碼裡，使得開發成本相對較高；另一方面，由於需要整合在應用內，使得需要針對不同語言（java、C、PHP……）有不同的實現（事實上sharding-jdbc目前只支援java），這樣元件本身的維護成本也會很高。最終將應用場景限定在由java開發的應用這一種場景下。

sharding-jdbc後續發展為Sharding-Sphere，包含sharding-jdbc、Sharding-Proxy、Sharding-Sidecar

       mycat是支援SQL92標準，遵守Mysql原生協議，跨語言，跨平臺，跨資料庫的通用中介軟體代理。作為對比可以參考上表中的Sharding-Proxy，需要單獨部署，由於遵守Mysql原生協議，應用時不需要特殊處理，和使用MySQL是一樣的，所以應用場景不受限制；但是mycat不支援二維路由，僅支援單庫多表或多庫單表，同時由於自定義連線池，這樣就會存在mycat自身維護一個連線池，MySQL也有一個連線池，任何一個連線池上限都會成為效能的瓶頸，而mycat的連線池設計也略顯粗暴，當請求連結數大於設定連線池上限時直接丟擲異常，因此在配置mycat連線池的大小是，需要結合場景做合理設定。總的來說，mycat以邏輯表的形式遮蔽掉應用處理分庫分表的複雜邏輯，遵守Mysql原生協議，跨語言，跨平臺，有著更為通用的應用場景。

       DRDS 相容 MySQL 協議和語法，支援分庫分表、平滑擴容、服務升降配、透明讀寫分離和分散式事務等特性，具備分散式資料庫全生命週期的運維管控能力。可以看成mycat的商業化產品，也就是mycat所有的優點它都有，而且作為一個商業化產品使用上更為簡單透明，功能也更為豐富；如果不差錢而且正準備對資料做重構，那麼drds是一個不錯的選擇，之所以說準備做資料重構時考慮用drds，是因為drds不是一個簡單的做sharding路由，即使原來使用的是rds，也無法通過drds做路由，唯一的辦法新建drds例項，定義路由規則（drds支援二維路由），匯入歷史資料，然後就可以開心的使用drds了。

     然後做個簡單總結