分庫分表，可能真的要退出歷史舞臺了！

原創：小姐姐味道（微信公眾號ID：xjjdog），歡迎分享，非公眾號轉載保留此宣告。

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

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

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

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

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

單機 MySQL 面臨很多問題。

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

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

很長時間以來，國內網際網路的做法普遍是採用加入一箇中介軟體的方式來解決，但隨著分散式資料庫的技術越來越成熟，這些魔法逐漸下沉到它本應該解決的層面--資料庫實現層。

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

解決上面三個單機 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 的案例，這屬於想吃螃蟹但並沒有吃到。目前來看，分散式資料庫越來越穩定，生態建設也越來越好。而分庫分表，則屬於存量業務，終將會退出歷史的舞臺。