2019年雙11成交額重要節點：
11月11日1分鐘超65億；
11月11日1分36秒，超100億；
11月11日5分25秒，超300億；
11月11日1小時3分59秒，超1000億；
11月11日1小時26分07秒，超1207億；
11月11日14小時21分，超2000億；
11月11日16小時31分，超2135億；
11月11日22點28分，超2500億元；
11月12日00點00分，成交額2684億。
一分鐘超65億的話，那麼也就是每秒鐘1個億的交易量，TPS>=1E
我們不妨設想下，如果採用MySQL數據庫，TPS>=1E，其核心交易系統的數據庫設計也是要進行分庫分表的，否則根本無法支持如此大規模的高性能併發寫入。
關於TPS的概念，請看我這篇文章，
那麼引入我們今天要討論的正題，分庫分表。目前數據庫的拆分形式，一般有兩種方式比較主流。
一、數據分片
- “數據分片” 通俗講，就是把數據庫服務器中的大表拆分成若干個小表（分片），這些分片可分佈在單臺/多臺數據庫服務器上。
- 分庫分表概念中的 “分片” 最小單位，指數據庫中的表。
二、垂直拆分
- 想象一下，一個數據庫的數據由一整塊豆腐組成。
- 我們根據不同的場景需要（炒菜、做湯、火鍋），將整塊豆腐垂直切成小豆腐塊，放到不同盤子裡。
- 盤子中的小豆腐塊，可以理解為數據庫中的“表”。
- 最終，不同的表會根據業務需要分散存儲到不同的數據庫中。
圖1
圖1中，我們使用了垂直分庫的思想，把熱點業務“考試”，單獨分出來一個數據庫，然後把“考試”相關的表，全部拉入新數據庫DB Examination中。
總體思路是，針對熱點業務，可以單獨的分出一個新庫來進行存儲，降低主庫的請求壓力。 後期可針對不同業務，單獨分出不同的數據庫。這個思路叫做垂直分庫，先理解這個概念。
三、水平拆分
- 開學季，某學校有很多新學生準備入學。
- 入學後，新生會根據所在地區進行分班。
- 假設每個班能夠容納30名學生，我們以“班級” 為單位，把眾多入學的學生，通過分班算法（根據所在地區進行分班），分配到不同的班級中。
- 班級 理解為“表”。
- 學校 理解為“數據庫”。
圖2
圖2中，我們使用了水平分表 的思想，在同一個數據庫中，由於突發需求（大批量新生轉院進入我校），那麼會導致學生表根本無法滿足現有業務需求，我們則需要對其進行水平拆分，分成多個學生表Student Table #0...#2。
總體思路是，針對熱點業務，在同一個數據庫下，按照不同的分片算法，分出多個數據表來滿足現有業務需求，降低單表的請求壓力。
仔細理解上述的知識點後，聰明的同學是否還會問到，那麼這兩種拆分的優缺點有哪些？
四、優劣對比
總結，我給大家的建議是，
任何的系統架構設計，都是為了簡單而穩定，不要盲目追求新技術而把事情搞複雜。
<code>能垂直分庫的場景，就不要考慮做水平分表。
必須要水平分表的話，那麼能分表就不要再分庫。
/<code>
閱讀更多 Java小虎 的文章
