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

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

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

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

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

單機 MySQL 面臨很多問題。

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

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

很長時間以來，國內(nèi)互聯(lián)網(wǎng)的做法普遍是采用加入一個中間件的方式來解決，但隨著分布式數(shù)據(jù)庫的技術(shù)越來越成熟，這些魔法逐漸下沉到它本應(yīng)該解決的層面--數(shù)據(jù)庫實現(xiàn)層。

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

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

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

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

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

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

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

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

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

當然，一旦你選用了分布式數(shù)據(jù)庫，以前的 DBA 經(jīng)驗可能就不管用了，比如說索引及其二級索引。你的團隊不得不學(xué)習新的知識，來應(yīng)對分布式環(huán)境。

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

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

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

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

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