即使是不懂編程的玩家，在對比 NAS 的時候，也會兩眼放光，考慮很多因素，比如 RAID 級別、速度、易用程度等。作為時時刻刻與代碼打交道的我們，更需要關注數據的存取問題。

一開始，開箱即用的 MySQL，一定是企業的首選。不僅僅因為用的人多，更重要的是生態成熟。要工具有工具，要人有人。對于老板來說，員工看著不爽，可以隨時辭退，是一個非常理想的狀態。

但是，沒有胸懷的老板，干的一定不會長久，因為如果商務會吹、老板會忽悠，業務會飛速發展（雖然現在這種機會比較少了）。對于 MySQL 來說，很快就會遇到問題。

這個時候，就需要一些比只會用 MySQL 級別高一些的人才，來配合老板圓夢。

是時候了，由單機 MySQL 向分布式發展了。

單機 MySQL 面臨很多問題。

• 單表太大，比如超過 500w，查詢就非常吃力
• 單庫太大，各種資源告急
• 讀請求太高，嚴重影響寫請求

對此，一堆概念也是騰空而出，比如分庫分表、讀寫分離等。

很長時間以來，國內互聯網的做法普遍是采用加入一個中間件的方式來解決，但隨著分布式數據庫的技術越來越成熟，這些魔法逐漸下沉到它本應該解決的層面--數據庫實現層。

留給分庫分表技術的時間，已經不多了，它的存量市場越來越少了。分庫分表技術，退出歷史舞臺，也是遲早的事情了。

解決上面三個單機 MySQL 問題，有很多種切入層面。比如，你簡單的在 MyBatis 或者 JPA 之上使用 AOP 或者攔截器封裝一層，也可以實現，這也是最傻的方式。

再進一步，就可以采用在 JDBC 之上的驅動層來實現，把分庫分表的路由維護在內存里，通過重寫的 DataSource、Connection、Statment、ResultSet等，對業務進行無侵入的改進。但可惜的是，我們還必須要維護與邏輯表相對應的物理表，而且功能也是閹割的，不確定性依然不小。更要命的是，JDBC 只支持 Java，對于某些公司來說，就非常的不適用。

再就是中間件的傳統模式，Proxy。把自己偽裝成一個MySQL Server，接受 Client 的請求。至于它后面怎么去操作真實的數據庫，你都不需要知道。但 Proxy 本身也是一套服務，你有運維成本在里面，同時功能依然是閹割的。

框架層，驅動層，代理層，在過去很長一段時間里，有無數的互聯網公司前赴后繼的試水，從 TDDL、Cobar，到 MyCat、ShardingSphere，各種層面的中間件也是層出不窮。但最近幾年，這種爭相斗艷的場面逐漸不再，到最后剩下來的，也就ShardingSphere這一枝獨秀了。

是問題不存在了么？不，正好相反，問題越來越嚴重。并不是問題消失了，而是它被轉化成其他解決方式了。

拋開關系型數據庫不說，很久之前，類似于 ElasticSearch、Cassandra這樣的 NoSQL 存儲，分片和副本的概念，就已經非常成熟了，而且它們是內置的，并不需要 DBA 去人工維護它們的物理位置。

對于關系型數據庫來說，走向分布式也終將成為必然。隨著 Raft 等協議應用越來越廣泛，分布式數據庫的可靠性也逐漸得到了保證。如果你以前因為事務問題而拒絕采用某些 NoSQL 產品，那么如今完全兼容 MySQL 的分布式數據庫，你沒有理由再說 No。

云廠商，直接提供了像Aurora、PolarDB之類的MySQL增強，更有類似 TiDB、OceanBase 這樣純粹的分布式數據庫，越來越多的業務走向了這個終途。當你的團隊加班加點驗證著分庫分表中間件的時候，卻發現其實換個兼容的存儲就能玩得轉，你會怎么選，簡直不用再多說。

當然，一旦你選用了分布式數據庫，以前的 DBA 經驗可能就不管用了，比如說索引及其二級索引。你的團隊不得不學習新的知識，來應對分布式環境。

但這些都是陣痛，長遠看來，分布式數據庫是趨勢，而分庫分表中間件只能吃存量。

當你的業務有了常年累積的復雜數據，你可能會采用復雜的分庫分表組件，但如果你的業務比較新，可預見的未來會有大量數據，那一個分布式數據庫可能是最合適的。

分庫分表中間件并不是消失了。它搖身一變，變成了分布式數據庫的一部分。

你可能會聽到很多切到分布式數據庫，又從分布式數據庫切回到 MySQL 的案例，這屬于想吃螃蟹但并沒有吃到。目前來看，分布式數據庫越來越穩定，生態建設也越來越好。而分庫分表，則屬于存量業務，終將會退出歷史的舞臺。

作者簡介：小姐姐味道 一個不允許程序員走彎路的公眾號。聚焦基礎架構和Linux。十年架構，日百億流量，與你探討高并發世界，給你不一樣的味道。