不要爲了「分庫分表」而「分庫分表」

爲何要進行分庫分表？

當數據庫的數據量過大，大到必定的程度，咱們就能夠進行分庫分表。那麼基於什麼原則，什麼方法進行拆分，這就是本篇所要講的。

爲何要進行分庫分表？當數據庫大到必定程度的時候，咱們採用優化硬件，優化表的結構，這種方法仍是沒法知足的時候，就要進行分庫分表。

分庫分表是什麼？

隨着公司的業務快速發展，數據庫中的數據量猛增，訪問性能也變慢了，優化迫在眉睫。

分析下問題出現哪裏呢？關係型數據自己就比較容易造成系統瓶頸，單機存儲容量，鏈接數，處理能力都有限。當單表的數據量達到1000W或100G之後，因爲查詢維度較多，即便添加從庫，優化索引，作不少操做時性能仍是降低嚴重。

方法一：

經過提高服務器硬件能力來提升數據處理能力，好比增長存儲容量，CPU等，這種方案成本很高，而且若是瓶頸在MySQL自己，那麼提升硬件也是頗有限的。

方法二：

將數據分散在不一樣的數據庫中，使得單一數據庫的數據量變小來緩解單一數據庫的性能問題，從而達到提高數據庫性能的目的。

好比，將電商的數據庫分爲若干個獨立的數據庫，而且對於大表也拆分爲若干小表，從而解決數據庫的性能問題。就跟把雞蛋放在多個籃子裏是同樣的。

因此，分庫分表就是爲了解決因爲數據量過大而致使數據庫性能下降的問題，將原來獨立的數據庫拆分爲若干數據庫，將數據庫大表拆分紅若干數據表，使得單一數據庫，單一數據表的數據量變小，從而達到提高數據庫性能的目的。

分庫分表的方式

咱們將電商做爲其背景，如今有三個表，分別是賣家表，商品表，店鋪表。

垂直分表

咱們平時逛淘寶等電商網站時，搜索列表的頁面顯示商品的關鍵信息，而點進去的頁面顯示商品的詳情信息。這個商品信息大表所包含的字段有不少，因此咱們將商品信息中經常使用的字段歸爲一個表，商品信息中不經常使用的字段歸爲一個表。

垂直分表的定義：將一個表按照字段分爲多表，每一個表裏面都存儲其中一部分字段。

他帶來的提高是：

1.爲了不IO爭搶並減小鎖表的概率，查看詳情的用戶與商品信息瀏覽互不影響。

2.充分發揮熱門數據（商品的基礎信息）的操做效率，商品信息的操做的高效率不會被商品描述的低效率所拖累。

爲何大字段效率低，好比商品表的描述信息？：第一是因爲數據量自己大，須要更長的讀取時間；第二是跨頁，頁是數據庫存儲單位，不少查找及定位操做都是以頁爲單位，單頁內的數據行越多數據庫總體性能越好，而大字段佔用空間大，單頁內存儲行數小，所以IO效率低；第三，數據庫以行爲單位將數據加載到內存中，這樣表中字段較短且訪問評率交到，內存能加載更多的數據，命中率更高，減小了磁盤IO，從而提高了數據庫性能。

通常來講，當表的數據量很大時，能夠將表按字段切開，將熱門字段和冷門字段分開，放在不一樣的表中，避免發生IO爭搶。

垂直分庫

經過垂直分表性能獲得必定程度的提高，可是尚未達到要求，而且磁盤空間已經不夠了，由於數據庫始終限制在一臺服務器上，庫內的垂直分表只解決了單一表數據量過大的問題，單沒有將表分佈到不一樣的服務器上，所以每一個表仍是競爭同一個物理機的CPU，內存，網絡IO，磁盤等物理資源。

因此，咱們能夠將賣家表，商品表，店鋪表分在不一樣的服務器中。

垂直分庫是指按照業務將表進行分類，分佈在不一樣的數據庫中，每一個庫能夠放在不一樣的服務器上，他的核心就是專庫專用。複製代碼

水平分庫

通過垂直分庫，數據庫性能問題獲得必定程度的解決，可是隨着業務量的增加，商品單褲存儲數據已經超出預估。粗略估計，目前有8w店鋪，每一個店鋪平均150個不一樣規格的商品，再算上增加，那商品數量得往1500w上預估，並且商品庫屬於訪問很是頻繁的資源，單臺服務器已經沒法支撐。此時，該如何優化。

嘗試水平分庫，將店鋪ID爲單數和店鋪ID爲雙數的商品信息分表放在兩個庫中。

水平分庫是把同一個表的數據按必定規則拆到不一樣的數據庫中，每一個庫能夠放在不一樣的服務器上。

他帶來的提高是：

解決了單庫大數據，高併發的性能瓶頸。

提升了系統的穩定性及可用性。（穩定性體如今IO衝突減小，鎖定減小，可用性指某個庫出問題，部分可用）

水平分表

水平分表是在同一個數據庫內，把同一個表的數據按必定的規則拆到多個表中。（對數據行拆分，不影響表結構）

他帶來的提高：

優化單一表數據量過大而產生的性能問題。

避免IO爭搶而減小鎖表的概率。

小結：

本小結介紹了分庫分表的各類方式，他們分別是垂直分表，垂直分庫，水平分庫和水平分表。

垂直分表：能夠吧一個寬表的字段按訪問頻次，是不是大字段的原則拆分爲多個表，這樣既能使業務清晰，還能提高部分性能，拆分後，儘可能從業務角度避免聯查，不然性能方面將得不償失。

垂直分庫：能夠把多個表按業務耦合鬆緊歸類，分別存放在不一樣的庫，這些庫能夠分佈在不一樣服務器，從而使訪問壓力被多服務器負載，大大提高性能，同事能提升總體架構的業務清晰度，不一樣的業務可根據自身狀況定製優化方案，可是他須要解決跨庫帶來的全部複雜問題。

水平分庫：能夠把一個表的數據（按數據行）分到多個不一樣的庫，每一個庫只有這個表的部分數據，這些庫能夠分佈在不一樣的服務器上，從而使訪問壓力被多服務器負載，大大提高性能，他不只須要解決跨庫帶來的全部複雜問題，還要解決數據路由的問題（數據路由問題後邊介紹）。

水平分表：能夠把一個表的數據（按數據行）分到同一個數據庫的多張表中，每一個表只有這個表的部分數據，這樣作能小幅提高性能，他僅僅做爲水平分庫的一個補充優化。

通常來講，在系統設計階段就應該根據業務耦合鬆緊來肯定垂直分庫，垂直分表方案，在數據量及訪問壓力不是特別大的狀況下，首先考慮緩存，讀寫分離，索引技術等方案，若數據量極大，且持續增加，再考慮水平分庫水平分表方案。

分庫分錶帶來的問題

分庫分表能有效的緩解了單機和單庫帶來的性能瓶頸和壓力，突破網絡IO，硬件資源，鏈接數的瓶頸，同時也帶來了一些問題。

事務一致性問題

因爲分庫分表把數據分佈在不一樣的庫甚至不一樣服務器，不可避免的帶來分佈式事務問題。

好比一個請求要先請求數據庫A，再請求數據庫B，這兩個屬於同一個事務，多個庫會致使分佈式事務問題。

跨節點關聯查詢

在沒有分庫前，咱們能夠很簡單的進行兩表的關聯查詢，可是分庫後，若是兩個表不在同一個數據庫，甚至不在同一臺服務器上，沒法進行關聯查詢。

能夠將原關聯查詢分爲兩次查詢，第一個查詢的結果找出關聯數據id，而後根據id發起第二次請求獲得關聯數據，最後將得到的數據進行拼裝。

跨節點分頁，排序函數

跨節點多庫進行查詢時，limit分頁，order by排序問題，就變得比較複雜，須要先在不一樣的分片節點中將數據進行排序並返回，而後將不一樣分片返回的結果集進行彙總和再次排序。

主鍵避重

在分庫分表環境中，因爲表中數據同時存在不一樣數據庫中，主鍵值平時使用的自增加將無用武之地，某個庫生成的ID沒法保證全局惟一。所以須要單獨設計全局主鍵，以便面跨庫主鍵重複問題。

公共表

實際應用場景中，參數表，數據字典表等都是數據量較小，變更少，並且屬於高頻聯合查詢的依賴表，可是其又沒有必要分庫分表，好比地理區域表也屬於此類型。

能夠將這類表在每一個數據庫都保存一份，全部對公共表的更新操做都同時發送到搜的分庫執行。

結語（重點）

如標題所示，咱們不能爲了分庫分表而分庫分表，首先咱們須要知道分庫分表的誕生是由於數據庫的性能瓶頸致使的，也就是若是沒有性能瓶頸，不必使用分庫分表，畢竟技術是爲了更好的服務於性能。其次，分庫分表也帶來了其餘的問題，不必時系統變得臃腫，不便。

即，一切以業務爲準，不能盲目追求技術的新穎，牛逼。

最後

關注偶哦，領取超多學習資料。