Mysql在數據量大的情況下，會遇到水平分表的情況。
1. 根據業務屬性拆表
這種分表方式的算法大致是取模，hash，md5等。
用業務屬性拆表，業務關系復雜的情況下，如果要根據其他條件查詢，其他的條件都必須和這個屬性關聯起來，查詢條件必須帶有這個屬性。
例子：
用戶profile表根據用戶ID取模進行水平拆分。
社區里有群組，群組里有應用，應用有各種類型。可以用群組ID，應用ID拆表。
問題：
根據某個條件查詢時無法獲取拆表的屬性
1) 條件中含有分表的信息
比如用戶在某網站下了訂單，我們根據用戶ID對訂單進行了分表，這樣用戶可以方便地查詢他所關聯的訂單。但用戶投訴時，客服需要根據訂單號查詢訂單，訂單號中可以含有分表的信息，比如訂單拆分成100張表，訂單號中可以有兩位用來表明該訂單處于哪張表中
2) 用key-value store存儲對應關聯
原理是用key value store做索引表
3) 數據冗余
需要關聯的表可以進行數據冗余。避免了查詢。
例子：
購買禮品。購買虛擬禮品時，我們根據了購買者的ID進行了拆表，同時訂單號中也含有了分表信息。但是用戶還可能根據被贈送方進行查詢，這時我們可以在購買成功后為被贈送方冗余生成一條記錄。
4) 緩存，NOSQL
和數據冗余類似。例子中提到的群組應用的拆表例子，我們已經按照群組ID和應用類型進行了分表。但是當我要查詢最近所有類型的應用時，就遇到困難了。我們需要把該群組的所有應用類型都查詢一遍，而且還要再進行排序，分頁等等。其實，可以用緩存的方式存儲最近幾百條應用。
2. 根據時間拆表
當表的關系比較復雜時，無法根據某個維度進行分表。但是有明顯的時效性。
例子：
想必大家都用微薄，某人發的微薄，會被推送到千家萬戶。所以某條微薄是無法根據用戶ID進行分表查詢。而微薄是有很強的時效性的。一年前的默認的動態信息是不會再關心的。我們把微薄按時間分表，三個月一張表。而行級緩存（memcached）只存儲了一個月。用戶微薄收件箱（微薄ID列表）一般都是限長的。當緩存服務器重啟或不命中時，需要查詢Mysql，mysql按時間分表，緩存不命中的情況下，大部分情況下都是查近三個月的微薄。所以近1年的微薄我們可以存儲在物理資源比較好的數據庫服務器上。
3. 根據自增長ID拆表
這種分割法不是取模分，而是每張表存指定量的數據。如果數據量到了，就存放到新表中。這樣可以完全控制每張表的數據量。關系非常簡單并且有時效性的情況下可以用。
4. 數據遷移的方式
當一些很久之前的數據，很少再查詢。比如員工工資表，我們可以只存今年的工資情況。而歷史數據我們可以遷移到一張salary_old表中,保證數據不會丟失。但也可以用來查詢。
分庫的原理也類似。