有了分散式資料庫，是不是就不需要分庫分表了？
現在各大廠都在推自己的分散式資料庫，比如騰訊的TDSQL、阿里的OceanBase，PolarDB、華為的GaussDB等。都號稱強一致高可用、全球部署架構、分散式水平擴展、高性能，實現了數千億條記錄、數百TB數據上的跨行跨表事務。既然這樣，是不是以後使用了分散式資料庫之後，就不需要再對自己的業務系統進行分庫分表操作了呢？
分散式資料庫不能阻止你把一個表或者庫搞的和宇宙爭大小, 用好資料庫永遠需要人的參與，系統無法解決這個問題
還需要，只是變得更隱蔽了。
分庫分表或者 sharding 的本質是摩爾定律的失效，單一節點的計算能力無法管理所有的應用狀態。由於在多個節點上維護同一份狀態並且保證彼此一致的成本太高，所以需要設計一組策略，把應用數據分成若干份，讓每一份數據路由到不同的節點進行處理。
這裡沒有太多技巧。研究過 paxos/raft 就會知道在不同節點間維持狀態一致性需要付出多大的成本。
sharding 機制引入了數據分布策略，目前的主流分散式資料庫都在嘗試屏蔽數據的分布，給用戶訪問一份完整數據的感覺。
這種處理方式實際上是一種封裝。封裝在什麼情況下會失效？
當用戶關注性能的時候。
儘管可以把 linklist 封裝成 array 但是 linklist 永遠無法提供與 array 相同的性能特性。
因此當應用關注性能的時候，會發現分散式資料庫的 sharding 策略實際決定了不同應用場景的訪問性能。這時候應用仍然需要關注 sharding，也就是關心數據在存儲上是如何真正分布的。
那樣我們又回到了分庫分表。
你說應用不關注性能？呃，那樣隨便用哪一個資料庫都可以，真的。
不需要分庫分表了，但是大多還會讓你指定拆分鍵。
即使 SQL 不帶 sharding key 也能執行，但是性能（尤其是 latency）也會打個折扣。
no silver bullet
分庫分表，乃至基於range、list或hash的分區表，都沒有做到對業務系統真正地透明，都帶來了或多或少的不便，都對業務系統不夠友好。資料庫的「透明地擴展」，應該是趨勢和主流，儘管還需要一段時間的努力。
一句話來回答的話，確實如此 --- 使用分散式資料庫後用戶就不需要再手動分庫分表了。幫用戶做分庫分表正是分散式資料庫的目標功能之一。另外，可以看看這個：
趙偉：崑崙分散式資料庫簡介?zhuanlan.zhihu.com
。
提問：」分散式資料庫之後，就不需要再對自己的業務系統進行分庫分表操作了「
1、數據分片 是分散式資料庫的基礎理論，也即要是採用默認的數據分片做法，例如：數據分片欄位默認是隱含欄位、主鍵活唯一索引則不需要人工去設置，數據分片演算法默認哈希（數據分片演算法有多種 哈希、範圍、路由），數據分片類型默認水平（數據分片類型有至少三種 水平、垂直、全局）。
要是想用業務欄位做數據分片，則需要好好設計一下，所以採用分散式資料庫後的難度體現在數據分片欄位的設計選擇上的 選那個分片欄位、那種分片演算法、那種分片類型。這樣對分散式資料庫產品廠商要求兩點： 要麼 實現一套智能演算法 為 每套業務系統 自動生成 數據分片設計方案 ，要麼資料庫產品廠商技術專家去人工完成。
2、可以肯定是：採用了分散式資料庫之後，業務系統研發工程 和資料庫管理員不需要考慮 數據分片的事情，或一句話說不需要考慮 分庫分表的事情，只是數據架構師設計的時候要考慮，然後在分散式資料庫中配置下，可以看下熱璞資料庫HotDB的可視化管理平台：
是也不是
- 分散式資料庫也無法避免，對於某些特殊表，要在運維層面手動設置分表邏輯，但是至少在應用層面可以不分了
- 某些帳套型數據，分表其實不止是性能問題，結算後數據就不能動了，分表會更好管理
只是不要手動分庫分表，並不代表內部實現沒有分庫分表，資料庫產品內部按照某種規則來幫助用戶自動在線擴容而已
另外自動分庫分表雖帶來了便利，但也帶來了其他問題，如一些功能受限，或者性能下降等等
雖然我不是專業後端，但是我覺得肯定不是你所說的那樣。
每個新出的技術都有它的優點，比如解決了什麼問題，但是也肯定有它自身的不足。
況且不談應用場景只談論技術實在是紙上談兵。你從北京往拉薩走，你會選擇坐輪船去么？
1.分散式資料庫又不是你心裡的蛔蟲，它怎麼知道你的業務到底要怎麼跑？所以根據自己的業務，合理地使用分表分庫來做負載均衡，才是正解。
2.不要太信宣傳廣告，特別是國內的。
分散式資料庫目標就是在提供可擴展性的同時保證資料庫的事務特性，從而解決以前單庫容量不足需要在業務層面進行分庫分表的問題 。從這個意義上說，你的問題答案是肯定的。
建議首先了解下分庫分表可以解決什麼問題，這些問題中有哪些是只用分散式資料庫或分區表方案還不能解決掉的。
舉個簡單的例子：單元化。
推薦閱讀：
