一、單庫單表存在的問題

假設你要設計一個電商網站，在一開始，User表、Order表、Product表等等各種表都在同一個數據庫中，每個表都包含了大量的字段。在用戶量比較少，訪問量也比較少的時候，單庫單表不存在問題。

但是公司可能發展的比較好，用戶量開始大量增加，業務也越來越繁雜。一張表的字段可能有幾十個甚至上百個，而且一張表存儲的數據還很多，高達幾千萬數據，更難受的是這樣的表還挺多。于是一個數據庫的壓力就太大了，一張表的壓力也比較大。試想一下，我們在一張幾千萬數據的表中查詢數據，壓力本來就大，如果這張表還需要關聯查詢，那時間等等各個方面的壓力就更大了。

（1）單庫太大：數據庫里面的表太多，所在服務器磁盤空間裝不下，IO次數多CPU忙不過來。

（2）單表太大：一張表的字段太多，數據太多。查詢起來困難。

此時就開始考慮如何解決問題了。

二、主從復制架構

單庫單表下越來越不滿足需求，此時我們先考慮進行讀寫分離。我們將數據庫的寫操作和讀操作進行分離， 使用多個從庫副本（Slaver）負責讀，使用主庫（Master）負責寫， 從庫從主庫同步更新數據，保持數據一致。

這在一定程度上可以解決問題，但是用戶超級多的時候，比如幾個億用戶，此時寫操作會越來越多，一個主庫（Master）不能滿足要求了，那就把主庫拆分，這時候為了保證數據的一致性就要開始進行同步，此時會帶來一系列問題：

（1）寫操作拓展起來比較困難，因為要保證多個主庫的數據一致性。

（2）復制延時：意思是同步帶來的時間消耗。

（3）鎖表率上升：讀寫分離，命中率少，鎖表的概率提升。

（4）表變大，緩存率下降：此時緩存率一旦下降，帶來的就是時間上的消耗。

注意，此時主從復制還是單庫單表，只不過復制了很多份并進行同步。

主從復制架構隨著用戶量的增加、訪問量的增加、數據量的增加依然會帶來大量的問題，那就要考慮換一種解決思路。就是今天所講的主題，分庫分表。 

三、分庫分表

不管是分庫還是分表，都有兩種切分方式：水平切分和垂直切分。下面我們分別看看如何切分。

1、分表

（1）垂直分表

表中的字段較多，一般將不常用的、 數據較大、長度較長的拆分到“擴展表“。一般情況加表的字段可能有幾百列，此時是按照字段進行數豎直切。注意垂直分是列多的情況。

（2）水平分表

單表的數據量太大。按照某種規則（RANGE,HASH取模等），切分到多張表里面去。但是這些表還是在同一個庫中，所以庫級別的數據庫操作還是有IO瓶頸。這種情況是不建議使用的，因為數據量是逐漸增加的，當數據量增加到一定的程度還需要再進行切分。比較麻煩。

2、分庫

（1）垂直分庫

一個數據庫的表太多。此時就會按照一定業務邏輯進行垂直切，比如用戶相關的表放在一個數據庫里，訂單相關的表放在一個數據庫里。注意此時不同的數據庫應該存放在不同的服務器上，此時磁盤空間、內存、TPS等等都會得到解決。

（2）水平分庫

水平分庫理論上切分起來是比較麻煩的，它是指將單張表的數據切分到多個服務器上去，每個服務器具有相應的庫與表，只是表中數據集合不同。水平分庫分表能夠有效的緩解單機和單庫的性能瓶頸和壓力，突破IO、連接數、硬件資源等的瓶頸。

四、分庫分表之后的問題

1、聯合查詢困難

聯合查詢不僅困難，而且可以說是不可能，因為兩個相關聯的表可能會分布在不同的數據庫，不同的服務器中。

2、需要支持事務

分庫分表后，就需要支持分布式事務了。數據庫本身為我們提供了事務管理功能，但是分庫分表之后就不適用了。如果我們自己編程協調事務，代碼方面就又開始了麻煩。

3、跨庫join困難

分庫分表后表之間的關聯操作將受到限制，我們無法join位于不同分庫的表，也無法join分表粒度不同的表， 結果原本一次查詢能夠完成的業務，可能需要多次查詢才能完成。我們可以使用全局表，所有庫都拷貝一份。

4、結果合并麻煩

比如我們購買了商品，訂單表可能進行了拆分等等，此時結果合并就比較困難。