分庫分表
1.垂直拆分 / 水平拆分？表太多 還是 數據太多？
如果是表太多,則應該將部分表進行遷移(可以按業務區分),這就是所謂的垂直切分。
如果是數據量太大,則需要將表拆成更多的小表,來減少單表的數據量,這就是所謂的水平拆分。
垂直拆分
垂直分庫
垂直分庫針對的是一個系統中的不同業務進行拆分,比如用戶一個庫,商品一個庫,訂單一個庫。 一個購物網站對外提供服務時,會同時對用戶、商品、訂單表進行操作。
垂直分表
表中的字段較多，將不常用的， 數據較大，長度較長（比如text類型字段）的拆分到“擴展表“。
水平拆分
水平分表
垂直分表是基於列的,而水平分表是基於全表的。
水平分庫分表
水平分庫分表能夠有效的緩解單機和單庫的性能瓶頸和壓力，突破IO、連接數、硬件資源等的瓶頸。
分庫分表策略
HASH取模
假設有用戶表user,將其分成3個表user0,user1,user2.路由規則是對3取模,當uid=1時,對應到的是user1,uid=2時,對應的是user2.
范圍分片
從1-10000一個表,10001-20000一個表。
地理位置分片
華南區一個表,華北一個表。
時間分片
按月分片，按季度分片等等,可以做到冷熱數據。
分庫分表注意點
分布式事務問題
如果我們做了垂直分庫或者水平分庫以后,就必然會涉及到跨庫執行SQL的問題,這樣就引發了互聯網界的老大難問題-"分布式事務"。那要如何解決這個問題呢？
1.使用分布式事務中間件 2.使用MySQL自帶的針對跨庫的事務一致性方案(XA),不過性能要比單庫的慢10倍左右。3.能否避免掉跨庫操作(比如將用戶和商品放在同一個庫中)
跨庫join的問題
分庫分表后表之間的關聯操作將受到限制，我們無法join位於不同分庫的表，也無法join分表粒度不同的表， 結果原本一次查詢能夠完成的業務，可能需要多次查詢才能完成。粗略的解決方法： 全局表：基礎數據，所有庫都拷貝一份。 字段冗余：這樣有些字段就不用join去查詢了。 系統層組裝：分別查詢出所有，然后組裝起來，較復雜。
跨節點Join的問題：解決這一問題的普遍做法是分兩次查詢實現
橫向擴容的問題
當我們使用HASH取模做分表的時候,針對數據量的遞增,可能需要動態的增加表,此時就需要考慮因為reHash導致數據遷移的問題。
結果集合並、排序的問題
因為我們是將數據分散存儲到不同的庫、表里的,當我們查詢指定數據列表時,數據來源於不同的子庫或者子表,就必然會引發結果集合並、排序的問題。如果每次查詢都需要排序、合並等操作,性能肯定會受非常大的影響。走緩存可能一條路!
Mycat
拆分工具：Mycat 分布式數據庫的中間件
關鍵詞：“攔截”，
它攔截了用戶發送過來的SQL語句，首先對SQL語句做了一些特定的分析：如分片分析、路由分析、讀寫分離分析、緩存分析等，
然后將此SQL發往后端的真實數據庫，並將返回的結果做適當的處理，最終再返回給用戶。
|
中間件
|
例如淘寶開源的cobar，以及后來開源社區根據cobar做二次開發的Mycat（個人建議如果使用中間件的話可以考慮Mycat）
|
|
Jar形式的開源工具
|
例如淘寶的TDDL，以及當當開源出來的，Sharding-JDBC等
|
|
動態數據源
|
根據自己的業務來指定數據源來完成不同庫和表的操作
|
邏輯庫
邏輯表
分片表
全局表
ER表（一對多關系）
非分片表
server.xml
schema.xml
rule.xml
Mycat和MySQL的區別（Mycat的核心作用）：
當我們的應用只需要一台數據庫服務器的時候我們並不需要Mycat，而如果你需要分庫甚至分表，這時候應用要面對很多個數據庫的時候，這個時候就需要對數據庫層做一個抽象，來管理這些數據庫，而最上面的應用只需要面對一個數據庫層的抽象或者說數據庫中間件就好了，這就是Mycat的核心作用。所以可以這樣理解：數據庫是對底層存儲文件的抽象，而Mycat是對數據庫的抽象。
分庫分表方案
1.熱數據和冷數據
熱數據：3個月內的訂單數據，查詢實時性較高。
冷數據A：3個月 ~ 12個月前的訂單數據，查詢頻率不高。
冷數據B：1年前的訂單數據，幾乎不會查詢，只有偶爾的查詢需求。
對於這三類數據的存儲，目前規划如下：
熱數據： 使用mysql進行存儲，當然需要分庫分表
冷數據A: 對於這類數據可以存儲在ES中，利用搜索引擎的特性基本上也可以做到比較快的查詢。
冷數據B: 對於這類不經常查詢的數據，可以存放到hive中
如何分庫分表
一、按業務拆分
我們將不同的業務放到不同的庫中，將原來所有壓力由同一個庫中分散到不同的庫中，提升了系統的吞吐量。