1. 前言
中大型項目中，一旦遇到數據量比較大，小伙伴應該都知道就應該對數據進行拆分了。有垂直和水平兩種。
垂直拆分比較簡單，也就是本來一個數據庫，數據量大之后，從業務角度進行拆分多個庫。如下圖，獨立的拆分出訂單庫和用戶庫。
水平拆分的概念，是同一個業務數據量大之后，進行水平拆分。
上圖中訂單數據達到了4000萬，我們也知道 MySQL 單表存儲量推薦是百萬級，如果不進行處理，mysql 單表數據太大，會導致性能變慢。使用方案可以參考數據進行水平拆分。把4000萬數據拆分4張表或者更多。當然也可以分庫，再分表；把壓力從數據庫層級分開。
1.1 垂直拆分和水平拆分區別
1.1.1 垂直拆分
數據庫的垂直拆分： 對業務表進行分類，不同的業務表劃分到不同的數據庫里。這種形式的拆分往往是便隨著服務化改造，按功能模塊將原來強耦合的系統拆分為多個弱耦合的服務，此時往往就會進行數據庫的垂直拆分。
數據表的垂直拆分： 是針對于數據表列的拆分，把一張列比較多的表拆分為多張表。
垂直拆分的優點：
- 數據庫的拆分簡單明了，拆分規則明確。
- 應用程序模塊清晰明確，整合容易。
- 數據維護方便易行，容易定位。
垂直拆分的缺點：
- 部分表關聯無法在數據庫級別完成，需要在程序中完成。
- 單表大數據量仍然存在性能瓶頸。
- 事務處理相對更為復雜。
- 拆分達到一定程度之后，擴展性會遇到限制。
1.1.2 水平拆分
把一個表的數據按照某種規則化分到不同表或數據庫里（水平拆分是按照行數據拆分）。
水平拆分的優點：
- 解決單表單庫大數據量和高熱點訪問性能遇到瓶頸的問題；
- 應用程序端整體架構改動相對較少。
- 事務處理相對簡單。
- 只要切分規則能夠定義好，基本上較難遇到擴展性限制。
水平拆分缺點：
- 拆分規則相對更復雜，很難抽象出一個能夠滿足整個數據庫的切分規則。
- 后期數據的維護難度有所增加，人為手工定位數據更困難。
- 產品邏輯將變復雜。比如按年來進行歷史數據歸檔拆分，這個時候在頁面設計上就需要約束用戶必須要先選擇年，然后才能進行查詢。
總而言之
- 數據表垂直拆分： 單表復雜度。
- 數據庫垂直拆分： 功能拆分。
- 水平拆分：分表：解決單表大數據量問題。 分庫：為了解決單庫性能問題。
2. 分庫分表方案
分庫分表方案中有常用的方案，hash取模和range范圍方案；分庫分表方案最主要就是路由算法，把路由的key按照指定的算法進行路由存放。接下來介紹一下兩個方案的特點。
2.1 hash取模方案
在我們設計系統之前，可以先預估一下大概這幾年的訂單量，如：4000萬。每張表我們可以容納1000萬，也我們可以設計4張表進行存儲。
那具體如何路由存儲的呢？hash的方案就是對指定的路由key（如：id）對分表總數進行取模，上圖中，id=12的訂單，對4進行取模，也就是會得到0，那此訂單會放到0表中。id=13的訂單，取模得到為1，就會放到1表中。為什么對4取模，是因為分表總數是4。
- 優點
訂單數據可以均勻的放到那4張表中，這樣此訂單進行操作時，就不會有熱點問題。
熱點的含義：熱點的意思就是對訂單進行操作集中到1個表中，其他表的操作很少。訂單有個特點就是時間屬性，一般用戶操作訂單數據，都會集中到這段時間產生的訂單。如果這段時間產生的訂單 都在同一張訂單表中，那就會形成熱點，那張表的壓力會比較大。
- 缺點
將來的數據遷移和擴容，會很難。
如：業務發展很好，訂單量很大，超出了4000萬的量，那我們就需要增加分表數。如果我們增加4個表
一旦我們增加了分表的總數，取模的基數就會變成8，以前id=12的訂單按照此方案就會到4表中查詢，但之前的此訂單時在0表的，這樣就導致了數據查不到。就是因為取模的基數產生了變化。
遇到這個情況，我們小伙伴想到的方案就是做數據遷移，把之前的4000萬數據，重新做一個hash方案，放到新的規劃分表中。也就是我們要做數據遷移。這個是很痛苦的事情。有些小公司可以接受晚上停機遷移，但大公司是不允許停機做數據遷移的。
當然做數據遷移可以結合自己的公司的業務，做一個工具進行，不過也帶來了很多工作量，每次擴容都要做數據遷移
那有沒有不需要做數據遷移的方案呢，我們看下面的方案
2.2 range范圍方案
range方案也就是以范圍進行拆分數據。
range方案比較簡單，就是把一定范圍內的訂單，存放到一個表中；如上圖id=12放到0表中，id=1300萬的放到1表中。設計這個方案時就是前期把表的范圍設計好。通過id進行路由存放。
- 優點
我們小伙伴們想一下，此方案是不是有利于將來的擴容，不需要做數據遷移。即時再增加4張表，之前的4張表的范圍不需要改變，id=12的還是在0表，id=1300萬的還是在1表，新增的4張表他們的范圍肯定是 大于 4000萬之后的范圍劃分的。
- 缺點
有熱點問題，我們想一下，因為id的值會一直遞增變大，那這段時間的訂單是不是會一直在某一張表中，如id=1000萬 ～ id=2000萬之間，這段時間產生的訂單是不是都會集中到此張表中，這個就導致1表過熱，壓力過大，而其他的表沒有什么壓力。
總結
hash取模方案：沒有熱點問題，但擴容遷移數據痛苦
range方案：不需要遷移數據，但有熱點問題。
那有沒有一個方案，即不需要遷移數據，又能解決數據熱點的問題呢？
