關于數據庫的分庫分表

來自： http://www.i3geek.com/archives/1108

什么是分庫分表

從字面上簡單理解，就是把原本存儲于一個庫的數據分塊存儲到多個庫上，把原本存儲于一個表的數據分塊存儲到多個表上。

為什么分庫分表

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

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

如何分庫分表

垂直切分

將表按照功能模塊、關系密切程度劃分出來，部署到不同的庫上。例如，我們會建立定義數據庫workDB、商品數據庫payDB、用戶數據庫userDB、日志數據庫logDB等，分別用于存儲項目數據定義表、商品定義表、用戶數據表、日志數據表等。

水平切分

當一個表中的數據量過大時，我們可以把該表的數據按照某種規則，例如userID散列，進行劃分，然后存儲到多個結構相同的表，和不同的庫上。例如，我們的userDB中的用戶數據表中，每一個表的數據量都很大，就可以把userDB切分為結構相同的多個userDB：part0DB、part1DB等，再將userDB上的用戶數據表userTable，切分為很多userTable：userTable0、userTable1等，然后將這些表按照一定的規則存儲到多個userDB上。

切分的選擇

應該使用哪一種方式來實施數據庫分庫分表，這要看數據庫中數據量的瓶頸所在，并綜合項目的業務類型進行考慮。

如果數據庫是因為表太多而造成海量數據，并且項目的各項業務邏輯劃分清晰、低耦合，那么規則簡單明了、容易實施的垂直切分必是首選。而如果數據庫中的表并不多，但單表的數據量很大、或數據熱度很高，這種情況之下就應該選擇水平切分，水平切分比垂直切分要復雜一些，它將原本邏輯上屬于一體的數據進行了物理分割，除了在分割時要對分割的粒度做好評估，考慮數據平均和負載平均，后期也將對項目人員及應用程序產生額外的數據管理負擔。

在現實項目中，往往是這兩種情況兼而有之，這就需要做出權衡，甚至既需要垂直切分，又需要水平切分。我們的游戲項目便綜合使用了垂直與水平切分，我們首先對數據庫進行垂直切分，然后，再針對一部分表，通常是用戶數據表，進行水平切分。

Mysql中的分庫分表

比如對于某網站平臺的數據庫表-公司表，數據量很大，這種能預估出來的大數據量表，我們就事先分出個N個表，這個N是多少，根據實際情況而定。某網站現在的數據量至多是5000萬條，可以設計每張表容納的數據量是500萬條，也就是拆分成10張表，那么如何判斷某張表的數據是否容量已滿呢？可以在程序段對于要新增數據的表，在插入前先做統計表記錄數量的操作，當<500萬條數據，就直接插入，當已經到達閥值，可以在程序段新創建數據庫表（或者已經事先創建好），再執行插入操作。

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

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

分庫分表存在的問題

事務問題

在執行分庫分表之后，由于數據存儲到了不同的庫上，數據庫事務管理出現了困難。如果依賴數據庫本身的分布式事務管理功能去執行事務，將付出高昂的性能代價；如果由應用程序去協助控制，形成程序邏輯上的事務，又會造成編程方面的負擔。

跨庫跨表的join問題

在執行了分庫分表之后，難以避免會將原本邏輯關聯性很強的數據劃分到不同的表、不同的庫上，這時，表的關聯操作將受到限制，我們無法join位于不同分庫的表，也無法join分表粒度不同的表，結果原本一次查詢能夠完成的業務，可能需要多次查詢才能完成。

額外的數據管理負擔和數據運算壓力

額外的數據管理負擔，最顯而易見的就是數據的定位問題和數據的增刪改查的重復執行問題，這些都可以通過應用程序解決，但必然引起額外的邏輯運算，例如，對于一個記錄用戶成績的用戶數據表userTable，業務要求查出成績最好的100位，在進行分表之前，只需一個order by語句就可以搞定，但是在進行分表之后，將需要n個order by語句，分別查出每一個分表的前100名用戶數據，然后再對這些數據進行合并計算，才能得出結果。

簡單的MySQL主從復制

MySQL的主從復制解決了數據庫的讀寫分離，并很好的提升了讀的性能，其圖如下：

其主從復制的過程如下圖所示：

但是，主從復制也帶來其他一系列性能瓶頸問題：

• 寫入無法擴展
• 寫入無法緩存
• 復制延時
• 鎖表率上升
• 表變大，緩存率下降

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

MySQL垂直分區

如果把業務切割得足夠獨立，那把不同業務的數據放到不同的數據庫服務器將是一個不錯的方案，而且萬一其中一個業務崩潰了也不會影響其他業務的正常進行，并且也起到了負載分流的作用，大大提升了數據庫的吞吐能力。經過垂直分區后的數據庫架構圖如下：

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

MySQL水平分片（Sharding）

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

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