單表資料量達到1000W以後，就要拆了.

背景情況

使用者表達到了 幾千萬級別，在做很多操作都比較吃力,.所以，考慮對其進行分表.

常用的切分方案

資料的切分（Sharding）根據其切分規則的型別，可以分為兩種切分模式。一種是按照不同的表（或者Schema）來切分到不同的資料庫（主機）之上，這種切可以稱之為資料的垂直（縱向）切分；另外一種則是根據表中的資料的邏輯關係，將同一個表中的資料按照某種條件拆分到多臺資料庫（主機）上面，這種切分稱之為資料的水平（橫向）切分。

垂直切分

即業務切分
下面來分析下垂直切分的優缺點：
優點：
 拆分後業務清晰，拆分規則明確。
 系統之間整合或擴充套件容易。
 資料維護簡單。
缺點：
 部分業務表無法 join，只能通過介面方式解決，提高了系統複雜度。
 受每種業務不同的限制存在單庫效能瓶頸，不易資料擴充套件跟效能提高。
 事務處理複雜。
由於垂直切分是按照業務的分類將表分散到不同的庫，所以有些業務表會過於龐大，存在單庫讀寫與儲存瓶
頸，所以就需要水平拆分來做解決。

水平切分

相對於垂直拆分，水平拆分不是將表做分類，而是按照某個欄位的某種規則來分散到多個庫之中，每個表中
包含一部分資料。簡單來說，我們可以將資料的水平切分理解為是按照資料行的切分，就是將表中的某些行切分到一個數據庫，而另外的某些行又切分到其他的資料庫中

幾種典型的分片規則包括：
 按照使用者 ID 求模，將資料分散到不同的資料庫，具有相同資料使用者的資料都被分散到一個庫中。
 按照日期，將不同月甚至日的資料分散到不同的庫中。
 按照某個特定的欄位求摸，或者根據特定範圍段分散到不同的庫中。
如圖，切分原則都是根據業務找到適合的切分規則分散到不同的庫，下面用使用者 ID 求模舉例：

優點：
 拆分規則抽象好，join 操作基本可以資料庫做。
 不存在單庫大資料，高併發的效能瓶頸。
 應用端改造較少。
 提高了系統的穩定性跟負載能力。
缺點：
 拆分規則難以抽象。
 分片事務一致性難以解決。
 資料多次擴充套件難度跟維護量極大。
 跨庫 join 效能較差。

切分共同的問題

前面講了垂直切分跟水平切分的不同跟優缺點，會發現每種切分方式都有缺點，但共同的特點缺點有：
 引入分散式事務的問題。
 跨節點 Join 的問題。
 跨節點合併排序分頁問題。
 多資料來源管理問題。

一般來講業務存在著複雜 join 的場景是難以切分的，往往業務獨立的易於切分。如何切分，切分到何種程度是考驗技術架構的一個難題。

切分的一些原則

由於資料切分後資料 Join 的難度在此也分享一下資料切分的經驗：
第一原則：能不切分儘量不要切分。
第二原則：如果要切分一定要選擇合適的切分規則，提前規劃好。
第三原則：資料切分儘量通過資料冗餘或表分組（Table Group）來降低跨庫 Join 的可能。
第四原則：由於資料庫中介軟體對資料 Join 實現的優劣難以把握，而且實現高效能難度極大，業務讀取儘量
少使用多表 Join。

資料庫的切分引申的 資料來源管理思考

主要有兩種思路：

A. 客戶端模式，在每個應用程式模組中配置管理自己需要的一個（或者多個）資料來源，直接訪問各個資料
庫，在模組內完成資料的整合；
B. 通過中間代理層來統一管理所有的資料來源，後端資料庫叢集對前端應用程式透明；

可能 90%以上的人在面對上面這兩種解決思路的時候都會傾向於選擇第二種，尤其是系統不斷變得龐大複雜
的時候。確實，這是一個非常正確的選擇，雖然短期內需要付出的成本可能會相對更大一些，但是對整個系統的擴充套件性來說，是非常有幫助的。

中介軟體

為了減少業務人員的壓力，
常用一些中介軟體，如 mycat Cobar
其結構大約如下圖

中介軟體的直接感受

這裡 簡單試用了下，mycat ，使用的例子是其官方例子
過程：
mysql 新建三個庫db1,db2,db3
在linux伺服器上 安裝mycat. 配置好mycat對三個庫，表的對應，mycat的rules 等.
後續使用時，將mycat 當作mysql來使用即可，
insert 三條資料進 mycat 的 TESTDB 的 travelrecord 表,
結果如下：
三條資料的實際儲存位置在db1,db2,db3中

參考資料