為什么要分庫分表？

首先回答一下為什么要分庫分表，答案很簡單：數據庫出現性能瓶頸。用大白話來說就是數據庫快扛不住了。

數據庫出現性能瓶頸，對外表現有幾個方面：

大量請求阻塞在高并發場景下，大量請求都需要操作數據庫，導致連接數不夠了，請求處于阻塞狀態。
SQL 操作變慢如果數據庫中存在一張上億數據量的表，一條 SQL 沒有命中索引會全表掃描，這個查詢耗時會非常久。
存儲出現問題業務量劇增，單庫數據量越來越大，給存儲造成巨大壓力。

從機器的角度看，性能瓶頸無非就是CPU、內存、磁盤、網絡這些，要解決性能瓶頸最簡單粗暴的辦法就是提升機器性能，但是通過這種方法成本和收益投入比往往又太高了，不劃算，所以重點還是要從軟件角度入手。

數據庫相關優化方案

數據庫優化方案很多，主要分為兩大類：軟件層面、硬件層面。

軟件層面包括：SQL 調優、表結構優化、讀寫分離、數據庫集群、分庫分表等；

硬件層面主要是增加機器性能。

SQL 調優

SQL 調優往往是解決數據庫問題的第一步，往往投入少部分精力就能獲得較大的收益。

SQL 調優主要目的是盡可能地讓那些慢 SQL 變快，手段其實也很簡單就是讓 SQL 執行盡量命中索引。

開啟慢 SQL 記錄

如果你使用的是 Mysql，需要在 Mysql 配置文件中配置幾個參數即可。

slow_query_log=on
long_query_time=1
slow_query_log_file=/path/to/log

調優的工具

常常會用到 explain 這個命令來查看 SQL 語句的執行計劃，通過觀察執行結果很容易就知道該 SQL 語句是不是全表掃描、有沒有命中索引。

select id, age, gender from  user where name = '愛笑的架構師';

返回有一列叫“type”，常見取值有：

ALL、index、range、 ref、eq_ref、const、system、NULL（從左到右，性能從差到好）

ALL 代表這條 SQL 語句全表掃描了，需要優化。一般來說需要達到range 級別及以上。

表結構優化

以一個場景舉例說明：

“user”表中有 user_id、nickname 等字段，“order”表中有order_id、user_id等字段，如果想拿到用戶昵稱怎么辦？一般情況是通過 join 關聯表操作，在查詢訂單表時關聯查詢用戶表，從而獲取到用戶昵稱。

但是隨著業務量增加，訂單表和用戶表肯定也是暴增，這時候通過兩個表關聯數據就比較費力了，為了取一個昵稱字段而不得不關聯查詢幾十上百萬的用戶表，其速度可想而知。

這個時候可以嘗試將 nickname 這個字段加到 order 表中（order_id、user_id、nickname），這種做法通常叫做數據庫表冗余字段。這樣做的好處展示訂單列表時不需要再關聯查詢用戶表了。

冗余字段的做法也有一個弊端，如果這個字段更新會同時涉及到多個表的更新，因此在選擇冗余字段時要盡量選擇不經常更新的字段。

架構優化

當單臺數據庫實例扛不住，我們可以增加實例組成集群對外服務。

當發現讀請求明顯多于寫請求時，我們可以讓主實例負責寫，從實例對外提供讀的能力；

如果讀實例壓力依然很大，可以在數據庫前面加入緩存如 redis，讓請求優先從緩存取數據減少數據庫訪問。

緩存分擔了部分壓力后，數據庫依然是瓶頸，這個時候就可以考慮分庫分表的方案了，后面會詳細介紹。

硬件優化

硬件成本非常高，一般來說不可能遇到數據庫性能瓶頸就去升級硬件。

在前期業務量比較小的時候，升級硬件數據庫性能可以得到較大提升；但是在后期，升級硬件得到的收益就不那么明顯了。

分庫分表詳解

下面我們以一個商城系統為例逐步講解數據庫是如何一步步演進。

單應用單數據庫

在早期創業階段想做一個商城系統，基本就是一個系統包含多個基礎功能模塊，最后打包成一個 war 包部署，這就是典型的單體架構應用。

如上圖，商城系統包括主頁 Portal 模板、用戶模塊、訂單模塊、庫存模塊等，所有的模塊都共有一個數據庫，通常數據庫中有非常多的表。

因為用戶量不大，這樣的架構在早期完全適用，開發者可以拿著 demo到處找（騙）投資人。

一旦拿到投資人的錢，業務就要開始大規模推廣，同時系統架構也要匹配業務的快速發展。

多應用單數據庫

在前期為了搶占市場，這一套系統不停地迭代更新，代碼量越來越大，架構也變得越來越臃腫，現在隨著系統訪問壓力逐漸增加，系統拆分就勢在必行了。

為了保證業務平滑，系統架構重構也是分了幾個階段進行。

第一個階段將商城系統單體架構按照功能模塊拆分為子服務，比如：Portal 服務、用戶服務、訂單服務、庫存服務等。

如上圖，多個服務共享一個數據庫，這樣做的目的是底層數據庫訪問邏輯可以不用動，將影響降到最低。

多應用多數據庫

隨著業務推廣力度加大，數據庫終于成為了瓶頸，這個時候多個服務共享一個數據庫基本不可行了。我們需要將每個服務相關的表拆出來單獨建立一個數據庫，這其實就是“分庫”了。

單數據庫的能夠支撐的并發量是有限的，拆成多個庫可以使服務間不用競爭，提升服務的性能。

如上圖，從一個大的數據中分出多個小的數據庫，每個服務都對應一個數據庫，這就是系統發展到一定階段必要要做的“分庫”操作。

現在非常火的微服務架構也是一樣的，如果只拆分應用不拆分數據庫，不能解決根本問題，整個系統也很容易達到瓶頸。

分表

說完了分庫，那什么時候分表呢？

如果系統處于高速發展階段，拿商城系統來說，一天下單量可能幾十萬，那數據庫中的訂單表增長就特別快，增長到一定階段數據庫查詢效率就會出現明顯下降。

因此，當單表數據增量過快，業界流傳是超過500萬的數據量就要考慮分表了。當然500萬只是一個經驗值，大家可以根據實際情況做出決策。

那如何分表呢？

分表有幾個維度，一是水平切分和垂直切分，二是單庫內分表和多庫內分表。

水平拆分和垂直拆分

就拿用戶表（user）來說，表中有7個字段：id,name,age,sex,nickname,description，如果 nickname 和 description 不常用，我們可以將其拆分為另外一張表：用戶詳細信息表，這樣就由一張用戶表拆分為了用戶基本信息表+用戶詳細信息表，兩張表結構不一樣相互獨立。但是從這個角度來看垂直拆分并沒有從根本上解決單表數據量過大的問題，因此我們還是需要做一次水平拆分。