[toc]

談一談分表設計

在一個可預見的，能運行比較長，數(shù)據(jù)量可能比較大的業(yè)務場景中，經(jīng)常需要分庫分表，因為單表存儲能力和查詢能力都是有上限的。一般如果業(yè)務還是要正常跑下去的話，都要進行遷移，比如遷移到能水平擴展的存儲（如tidb, mongodb等）。但是在初期，業(yè)務還沒有起量的時候或者說不能預見能起量的時候，都是采用傳統(tǒng)的分庫分表方法來解決。這篇文章只談分表。

需要分表的場景

一般來說，數(shù)據(jù)是膨脹類增長時，比如線性增長，指數(shù)增長，這些場景都需要分表。舉個例子，用戶訂單表，購買記錄流水表，收支流水記錄，發(fā)放記錄流水，操作記錄表。一個用戶的操作可能產(chǎn)生幾倍的數(shù)據(jù)增長。

分表設計的原則

• 滿足業(yè)務的需求
• 能保持數(shù)據(jù)不惡化

說下不惡化這個原則，也就是在業(yè)務隨著時間向前推進增長的情況下，系統(tǒng)能正常運行。

常用分表方法

• 根據(jù)業(yè)務id做shardKey(取?；蛘遠ash, 或者某類算法)分表

• 根據(jù)時間分表(年月日相關)

• 分表冗余表(路由表)

前2種一般都有用到。這里說一下第三種
有時按第一種分表，數(shù)據(jù)變得難以查詢，比如訂單表，假定表結包含如下字段

orderId 訂單id
uid 用戶id
money 訂單金額
itemid 商品id

如果存儲是按照格式，會發(fā)現(xiàn)，如果用戶來查詢自己的訂單，就比較難查詢。
這時需要再存儲一個對應關，簡稱路由表，按uid來分表，存儲orderId

最優(yōu)分表方法

其實沒有什么最優(yōu)方法，只有適合的才是最好的。

但是對于分表的的情況，如是數(shù)據(jù)有冷熱之分，比如只查詢最近的，一個月前的幾乎不會查詢到，則需要根據(jù)時間更佳，如果擔心分月單表壓力大，可能再根據(jù)uid來分一次，不會隨著時間，表里面的數(shù)量膨脹到最終爆炸。

數(shù)據(jù)庫分表是解決單表海量數(shù)據(jù)的查詢性能問題。

有些表是沒有冷熱之分，比如商品表，這個時候就需要分庫了，解決單庫并發(fā)訪問壓力, 一個不行，多來幾個。