分庫分表概述
讀寫分離分散數據庫讀寫操作壓力，分庫分表分散存儲壓力
適用場景
類似讀寫分離，分庫分表也是確定沒有其他優化空間之後才採取的優化方案。那如果業務真的發展很快豈不是很快要進行分庫分表了？那為何不一開始就設計好呢？
按照架構設計的“三原則”（簡單原則，合適原則，演化原則），簡單分析一下：
首先，這裡的“如果”事實上發生的概率比較低，做10個業務有一個業務能活下去就很不錯了，更何況快速發展，和中彩票的概率差不多。如果我們每個業務上來就按照淘寶、微信的規模去做架構設計，不但會累死自己，還會害死業務。
其次，如果業務真的發展很快，後面進行分庫分表也不遲。因為業務發展好，相應的資源投入就會加大，可以投入更多的人和更多的錢，那業務分庫帶來的代碼和業務複雜問題就可以通過加人來解決，成本問題也可以通過增加資金來解決。
業務分庫
業務分表概述
帶來的問題：垂直分表、增加表操作的次數、水平分表
路由問題
數據庫操作問題
實現方法
類似讀寫分離，具體實現也是“程序代碼封裝”和“中間件封裝”，但具體實現複雜一些，因為還有要判斷SQL中具體操作的表，具體操作(例如count、order by、group by等)，根據具體操作做不同的處理。
最後
歡迎大家關注我新開通的公眾號【風平浪靜如碼】，最新最全多家公司java面試題整理了1000多道400多頁pdf文檔，文章都會在裡面更新，整理的資料也會放在裡面。
喜歡文章記得關注我點個贊喲，感謝支持！
分享到:
閱讀更多 愛喝王老吉的劉某人 的文章
