MySQL分庫分表方案

1.爲何要分表：

當一張表的數據達到幾千萬時，你查詢一次所花的時間會變多，若是有聯合查詢的話，我想有可能會死在那兒了。分表的目的就在於此，減少數據庫的負擔，縮短查詢時間。

mysql中有一種機制是表鎖定和行鎖定，是爲了保證數據的完整性。表鎖定表示大家都不能對這張表進行操做，必須等我對錶操做完才行。行鎖定也同樣，別的sql必須等我對這條數據操做完了，才能對這條數據進行操做。

2. mysql proxy：amoeba

作mysql集羣,利用amoeba。

從上層的java程序來說，不須要知道主服務器和從服務器的來源，即主從數據庫服務器對於上層來說是透明的。能夠經過amoeba來配置。

3.大數據量而且訪問頻繁的表，將其分爲若干個表

好比對於某網站平臺的數據庫表-公司表，數據量很大，這種能預估出來的大數據量表，咱們就事先分出個N個表，這個N是多少，根據實際狀況而定。

某網站如今的數據量至可能是5000萬條，能夠設計每張表容納的數據量是500萬條，也就是拆分紅10張表，

那麼如何判斷某張表的數據是否容量已滿呢？能夠在程序段對於要新增數據的表，在插入前先作統計表記錄數量的操做，當<500萬條數據，就直接插入，當已經到達閥值，能夠在程序段新建立數據庫表（或者已經事先建立好），再執行插入操做。

4. 利用merge存儲引擎來實現分表

若是要把已有的大數據量表分開比較痛苦，最痛苦的事就是改代碼，由於程序裏面的sql語句已經寫好了。用merge存儲引擎來實現分表, 這種方法比較適合.

舉例子：

------------------- ----------華麗的分割線--------------------------------------

數據庫架構

一、簡單的MySQL主從複製:

MySQL的主從複製解決了數據庫的讀寫分離，並很好的提高了讀的性能，其圖以下：

其主從複製的過程以下圖所示：

可是，主從複製也帶來其餘一系列性能瓶頸問題：

1. 寫入沒法擴展

2. 寫入沒法緩存

3. 複製延時

4. 鎖表率上升

5. 表變大，緩存率降低

那問題產生總得解決的，這就產生下面的優化方案，一塊兒來看看。

二、MySQL垂直分區

若是把業務切割得足夠獨立，那把不一樣業務的數據放到不一樣的數據庫服務器將是一個不錯的方案，並且萬一其中一個業務崩潰了也不會影響其餘業務的正常進行，而且也起到了負載分流的做用，大大提高了數據庫的吞吐能力。通過垂直分區後的數據庫架構圖以下：

然而，儘管業務之間已經足夠獨立了，可是有些業務之間或多或少總會有點聯繫，如用戶，基本上都會和每一個業務相關聯，何況這種分區方式，也不能解決單張表數據量暴漲的問題，所以爲什麼不試試水平分割呢？

三、MySQL水平分片（Sharding）

這是一個很是好的思路，將用戶按必定規則（按id哈希）分組，並把該組用戶的數據存儲到一個數據庫分片中，即一個sharding，這樣隨着用戶數量的增長，只要簡單地配置一臺服務器便可，原理圖以下：

如何來肯定某個用戶所在的shard呢，能夠建一張用戶和shard對應的數據表，每次請求先從這張表找用戶的shard id，再從對應shard中查詢相關數據，以下圖所示：