又到一年春招時，準備找工作或者是準備換工作的小夥伴，肯定都忙著看面經、刷題等各種操作。作為一個出現頻率超高的面試題，今天總結一波。主要是對分庫分表的原理進行解析。不涉及具體操作。
這篇文章的脈絡如下：
1、分庫分表之前出現的問題
2、怎麼分庫分表？
3、分庫分表的規則是什麼？
下面按照這個脈絡給出今天的文章。
一、單庫單表存在的問題
假設你要設計一個電商網站，在一開始，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、結果合併麻煩
比如我們購買了商品，訂單表可能進行了拆分等等，此時結果合併就比較困難。
OK，這篇文章寫完之後感覺還會做大量的補充和修改。因此本篇文章主要針對面試，足夠。
閱讀更多 Java的架構師技術棧 的文章
