首先分庫分表分為垂直和水平兩個(gè)方式，一般來說我們拆分的順序是先垂直后水平。

　　垂直分庫

　　基于現(xiàn)在微服務(wù)拆分來說，都是已經(jīng)做到了垂直分庫了

　　垂直分表

　　垂直切分是將一張表按列切分成多個(gè)表，通常是按照列的關(guān)系密集程度進(jìn)行切分，也可以利用垂直切分將經(jīng)常被使用的列和不經(jīng)常被使用的列切分到不同的表中。

　　在數(shù)據(jù)庫的層面使用垂直切分將按數(shù)據(jù)庫中表的密集程度部署到不同的庫中，例如將原來的電商數(shù)據(jù)庫垂直切分成商品數(shù)據(jù)庫、用戶數(shù)據(jù)庫等。

　　水平分表

　　首先根據(jù)業(yè)務(wù)場景來決定使用什么字段作為分表字段(sharding_key)，比如我們現(xiàn)在日訂單1000萬，我們大部分的場景來源于C端，我們可以用user_id作為sharding_key，數(shù)據(jù)查詢支持到最近3個(gè)月的訂單，超過3個(gè)月的做歸檔處理，那么3個(gè)月的數(shù)據(jù)量就是9億，可以分1024張表，那么每張表的數(shù)據(jù)大概就在100萬左右。

　　比如用戶id為100，那我們都經(jīng)過hash(100)，然后對(duì)1024取模，就可以落到對(duì)應(yīng)的表上了。

　　那分表后的ID怎么保證唯一性的呢?

　　因?yàn)槲覀冎麈I默認(rèn)都是自增的，那么分表之后的主鍵在不同表就肯定會(huì)有沖突了。有幾個(gè)辦法考慮：

　　設(shè)定步長，比如1-1024張表我們分別設(shè)定1-1024的基礎(chǔ)步長，這樣主鍵落到不同的表就不會(huì)沖突了。

　　分布式ID，自己實(shí)現(xiàn)一套分布式ID生成算法或者使用開源的比如雪花算法這種

　　分表后不使用主鍵作為查詢依據(jù)，而是每張表單獨(dú)新增一個(gè)字段作為唯一主鍵使用，比如訂單表訂單號(hào)是唯一的，不管最終落在哪張表都基于訂單號(hào)作為查詢依據(jù)，更新也一樣。