這裏分享一個分析、設計、架構。方便大家規劃自己的道路。
以蓋樓爲例子
分析：要知道用戶想蓋什麼樣子的樓（做系統的時候，就是搞懂用戶的需求，理解需求）
設計：按照用戶想要的，設計師把用戶的樓設計出來（按照prd，做系統設計、系統分析）
架構：樓按照設計師的方案，能否滿足承重、能否滿足以後的水電、是否方便以後用戶的裝修（按照系分設計，能否滿足系統的穩定性，可擴展性，以及對整體的規劃）
爲什麼要分庫、分表？
單表的數據量限制，當單表數據量到一定條數之後數據庫性能會顯著下降。數據多了之後，對數據庫的讀、寫就會很多。分庫減少單臺數據庫的壓力。
背景：
接觸過幾個分庫分表的系統，都是通過主鍵進行散列分褲分表的。這類數據比較特殊，主鍵就是唯一的獲取該條信息的主要途徑。比如：京東的訂單、財付通的交易記錄等。。。該類數據的用法，就是通過訂單號、交易號來查詢該筆訂單、交易。
還有一類數據，比如用戶信息，每個用戶都有系統內部的一個userid，與userid對應的還有用戶看到的登錄名。那麼如果分庫分表的時候單純通過userid進行散列分庫，那麼根據登錄名來獲取用戶的信息，就無法知道該用戶處於哪個數據庫中。
或許有朋友會說，我們可以維護一個email----userid的映射關係，根據email先查詢到userid，在根據userid的分庫分表規則到對應庫的對應表來獲取用戶的記錄信息。這麼做是可以的，但是這個映射關係的條數本身也是個瓶頸，原則上是沒有減少單表內數據的條數，算是一個單點。並且要維護這個映射關係和用戶信息的一致性（修改登錄名、多登錄名等其他特殊需求），最大一個原因，其實用戶信息是一個讀大於寫的庫，web2.0都是以用戶爲中心，所有信息都和用戶信息相關聯，所以對用戶信息拆分還是有一定侷限性的。
對於這類讀大於寫並且數據量增加不是很明顯的數據庫，推薦採用讀寫分離+緩存的模式，試想一下一個用戶註冊、修改用戶信息、記錄用戶登錄時間、記錄用戶登錄IP、修改登錄密碼，這些是寫操作。但是以上這些操作次數都是很小的，所以整個數據庫的寫壓力是很小的。唯一一個比較大的就是記錄用戶登錄時間、記錄用戶登錄IP這類信息，只要把這些經常變動的信息排除在外，那麼寫操作可以忽略不計。所以讀寫分離首要解決的就是經常變化的數據的拆分，比如：用戶登錄時間、記錄用戶登錄IP。這類信息可以單獨獨立出來，記錄在持久化類的緩存中（可靠性要求並不高，登陸時間、IP丟了就丟了，下次來了就又來了）
以oracle爲例，主庫負責寫數據、讀數據。讀庫僅負責讀數據。每次有寫庫操作，同步更新cache，每次讀取先讀cache在讀DB。寫庫就一個，讀庫可以有多個，採用dataguard來負責主庫和多個讀庫的數據同步。
對於，其他類型的數據，博客的日誌表，電商的訂單表，支付公司的交易流水錶都可以採用分褲分表的形式。
比如：支付寶每天數千萬筆交易，假設數據庫提供一年的記錄信息查詢，一年後轉入，那麼就是數十億的數據，假設採用單庫單表，這個壓力肯定是抗不住的。所以可以採用按照交易號來進行分庫分表，達到水平的擴展。