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