一開始考慮使用ProxySQL+MGR來實現資料庫切換應用無感知方向，考慮了可能的兩種部署模型的優缺點：
ProxySQL部署的兩種模型：
1、靠近應用端
方式：在應用伺服器上直接部署
優點：
  A、每個應用伺服器有自己的配置 ，配置內容簡單，不容易相互影響故障，變更故障風險最小
  B、沒有瓶頸壓力，故障容錯最好，單機故障影響最小
  C、資料庫上可以清楚看到SQL來自哪臺應用機器，方便排查故障
  D、無需單獨機器資源
缺點：
  A、每臺應用伺服器上都需要配置，當資料庫架構擴容或者其他變動時，需要應用則的ProxySQL做相應改動
  B、當一臺應用上需要連線多套資料庫時，配置也會開始稍微複雜
2、靠近資料庫端
方式：通過獨立的ProxySQL叢集來提供服務
優點：
  A、不需要每臺應用伺服器上配置，集中修改
缺點：
  A、容易出現瓶頸，網路、機器效能等
  B、集中配置，導致配置非常複雜，可能相互影響，變更故障風險高
  C、全部應用通過ProxySQL來連線，資料庫上看到具體問題連線來自哪臺應用機器，無法進行故障定位
  D、需要單獨的機器資源來部署ProxySQL，因為流量集中且是應用層，需要考慮效能瓶頸，佔用機器資源相對較多
  E、機器故障時，影響是面級，通過額外高可用技術來減少影響


綜合上面的優缺點，ProxySQL+MGR來實現應用切換無感知方式並不大合適，haproxy等方案也有類似問題，建議：
1、使用浮動IP來實現Mysql MGR的寫高可用（浮動IP需要自己實現）
2、使用LVS來實現Mysql MGR或者普通複製（擴充套件庫）讀庫的高可用和負載均衡

3、使用DNS域名切換來實現不同機房的切換

角色職責分層的思考：
1、資料庫層
  A、負責資料庫CELL級別高可用方案，提供寫高可用入口與讀高可用入口
  B、多個邏輯庫從一個CELL拆到多個CELL
2、需要應用層考慮的：
  A、讀寫分離邏輯
  B、邏輯庫的分庫分表
為什麼歸到應用層，這些讀寫分離邏輯與分庫分表邏輯，更加接近應用層的資料理解，所以目前的真正獨立的資料庫中介軟體好像沒有真大互聯公司的實際考驗，已經知道的使用應用側分庫分表元件的網際網路公司有：
  A、阿里--TDDL
  B、噹噹--sharding-jdbc，已經開源
  C、原大眾點評--Zebra
  D、美團--MTDDL（Meituan Distributed Data Layer），參考連結：https://tech.meituan.com/mtddl.html
也有使用proxy方案的，如京東自己開發JProxy，但也是根據自己業務特點開發的。

ProxySQL的應用方向應該是公司沒有能力開發自己的中介軟體元件時使用，但應該在應用端使用，應用層需要在應用中考慮使用配置，並在應用伺服器上直接部署，由於底層的資料庫CELL提供給應用層的讀介面、寫介面已經在高可用和效能可擴充套件，配置只需要考慮業務邏輯與邏輯庫的關係，不需要考慮資料庫的機器細節：
1、應用層沒有自己讀寫分離實現方案，在應用端使用，用於實現讀寫分離

2、應用層沒有自己分庫分表實現方案，在應用端使用，用於實現分庫分表

其實也應該考慮開源的元件如sharding-jdbc