資料量大就分表，并發高就分庫。
如果是創業公司。比如注冊使用者20w,
每天日活1w, 每天單表1000， 高峰期每秒并發 10 ，這個時候，一般不需要考慮分庫分表，如果注冊使用者2000w, 日活100w,
單表10w條，高峰期每秒并發1000，此時就要考慮分庫分表。當然多加幾台機器，使用負載均衡可以扛住，但是每天單表資料增加，磁盤資源會被消耗掉，高峰期如果要5000
怎麼辦，系統肯定撐不住。也就是說，資料增加，請求量增大，并發增大，單個資料庫肯定不行。
如果單表資料達到 幾千萬了，資料量比較大，會極大影響 sql 查詢性能， 後面的sql 執行會很慢，經驗來說，單表資料幾百萬，就要考慮分表了。
所謂的分表，就是将一個表的資料存放到多個表中， 查詢的時候就查一個表。比如按照使用者 id 來分表，将一個使用者的資料存放在一個表中，然後對這個使用者操作時操作那個表就好。一般來說，每個表的資料固定在 200w 以内比較好。
所謂的垂直拆分，就是将一個表中的列拆分到多個表中，也就是說将一個大表拆分成多個小表。
常用的列放在一個表，不常用的列放在其他表
關系緊密的列放在一個表
大字段列單獨存放
在這裡插入圖檔描述
表結構保持不變， 對資料進行拆分，将表中對某些行拆分到其他表中。
分庫， 經驗來說，一個庫對并發最多到 2000， 一定要擴容，一個健康的單庫并發控制在1000 qps 左右，如果超過，那麼将一個庫的資料拆分到多個庫。
代表産品是 mycat, sql組合，資料庫路由，執行結果合并都放到一個代理服務中。
無代碼侵入性， 支援多種語言
需要額外引入中間件， 容易造成流量瓶頸
常見的有 sharing-jdbc, 業務端系統隻要引入一個 jar 包即可，按照規範配置路由規則， jar 包中處理資料庫路由，sql 組合，執行結果合并等操作。
簡單，容易上手，引入 jar 包即可，無流量瓶頸
更新麻煩，更新 jar 包時，往往需要更新服務
資料盡量均勻等分布在不同等庫或者不同表，避免資料傾斜。
跨庫操作盡量少
這個字段的值不會變化。
hash 分片
range 分片（範圍分片）
增量資料監聽 binlog,通過 canal 增量遷移資料
全量遷移曆史資料
開啟雙寫，關閉增量遷移任務。
讀業務切換到新庫
線上運作一段時間，沒有問題後，下線老庫。
簡單來說，對新庫，老庫都操作。要注意的是不允許老資料覆寫新資料。
如何設計可以動态擴容縮容的分庫分表方案？
https://mp.weixin.qq.com/s/m6j5nixyxc8zyoghnokaba