在文章開頭先拋幾個問題：
（1）什么時候才需要分庫分表呢款熬？我們的評判標(biāo)準(zhǔn)是什么挣柬？
（2）一張表存儲了多少數(shù)據(jù)的時候钥顽，才需要考慮分庫分表？
（3）數(shù)據(jù)增長速度很快舞箍，每天產(chǎn)生多少數(shù)據(jù)舰褪，才需要考慮做分庫分表？
這些問題你都搞清楚了嗎疏橄？相信看完這篇文章會有答案占拍。
為什么要分庫分表？
首先回答一下為什么要分庫分表捎迫，答案很簡單：數(shù)據(jù)庫出現(xiàn)性能瓶頸晃酒。用大白話來說就是數(shù)據(jù)庫快扛不住了。
數(shù)據(jù)庫出現(xiàn)性能瓶頸窄绒，對外表現(xiàn)有幾個方面：
-
大量請求阻塞
在高并發(fā)場景下贝次，大量請求都需要操作數(shù)據(jù)庫，導(dǎo)致連接數(shù)不夠了彰导，請求處于阻塞狀態(tài)蛔翅。
-
SQL 操作變慢
如果數(shù)據(jù)庫中存在一張上億數(shù)據(jù)量的表，一條 SQL 沒有命中索引會全表掃描螺戳，這個查詢耗時會非常久搁宾。
-
存儲出現(xiàn)問題
業(yè)務(wù)量劇增折汞，單庫數(shù)據(jù)量越來越大倔幼，給存儲造成巨大壓力。
從機器的角度看爽待，性能瓶頸無非就是CPU损同、內(nèi)存、磁盤鸟款、網(wǎng)絡(luò)這些膏燃，要解決性能瓶頸最簡單粗暴的辦法就是提升機器性能，但是通過這種方法成本和收益投入比往往又太高了何什，不劃算组哩，所以重點還是要從軟件角度入手。
數(shù)據(jù)庫相關(guān)優(yōu)化方案
數(shù)據(jù)庫優(yōu)化方案很多处渣，主要分為兩大類：軟件層面伶贰、硬件層面。
軟件層面包括：SQL 調(diào)優(yōu)罐栈、表結(jié)構(gòu)優(yōu)化黍衙、讀寫分離、數(shù)據(jù)庫集群荠诬、分庫分表等琅翻；
硬件層面主要是增加機器性能位仁。
SQL 調(diào)優(yōu)
SQL 調(diào)優(yōu)往往是解決數(shù)據(jù)庫問題的第一步，往往投入少部分精力就能獲得較大的收益方椎。
SQL 調(diào)優(yōu)主要目的是盡可能的讓那些慢 SQL 變快聂抢，手段其實也很簡單就是讓 SQL 執(zhí)行盡量命中索引。
開啟慢 SQL 記錄
如果你使用的是 Mysql棠众，需要在 Mysql 配置文件中配置幾個參數(shù)即可涛浙。
slow_query_log=on
long_query_time=1
slow_query_log_file=/path/to/log
調(diào)優(yōu)的工具
常常會用到 explain 這個命令來查看 SQL 語句的執(zhí)行計劃，通過觀察執(zhí)行結(jié)果很容易就知道該 SQL 語句是不是全表掃描摄欲、有沒有命中索引轿亮。
select id, age, gender from user where name = '愛笑的架構(gòu)師';
返回有一列叫“type”，常見取值有：
ALL胸墙、index我注、range、 ref迟隅、eq_ref但骨、const、system智袭、NULL（從左到右奔缠，性能從差到好）
ALL 代表這條 SQL 語句全表掃描了，需要優(yōu)化吼野。一般來說需要達(dá)到range 級別及以上校哎。
表結(jié)構(gòu)優(yōu)化
以一個場景舉例說明：
“user”表中有 user_id、nickname 等字段瞳步，“order”表中有order_id闷哆、user_id等字段，如果想拿到用戶昵稱怎么辦单起？一般情況是通過 join 關(guān)聯(lián)表操作抱怔，在查詢訂單表時關(guān)聯(lián)查詢用戶表，從而獲取導(dǎo)用戶昵稱嘀倒。
但是隨著業(yè)務(wù)量增加屈留，訂單表和用戶表肯定也是暴增，這時候通過兩個表關(guān)聯(lián)數(shù)據(jù)就比較費力了测蘑，為了取一個昵稱字段而不得不關(guān)聯(lián)查詢幾十上百萬的用戶表灌危，其速度可想而知。
這個時候可以嘗試將 nickname 這個字段加到 order 表中（order_id帮寻、user_id乍狐、nickname），這種做法通常叫做數(shù)據(jù)庫表冗余字段固逗。這樣做的好處展示訂單列表時不需要再關(guān)聯(lián)查詢用戶表了浅蚪。
冗余字段的做法也有一個弊端藕帜，如果這個字段更新會同時涉及到多個表的更新，因此在選擇冗余字段時要盡量選擇不經(jīng)常更新的字段惜傲。
架構(gòu)優(yōu)化
當(dāng)單臺數(shù)據(jù)庫實例扛不住洽故，我們可以增加實例組成集群對外服務(wù)。
當(dāng)發(fā)現(xiàn)讀請求明顯多于寫請求時盗誊，我們可以讓主實例負(fù)責(zé)寫时甚，從實例對外提供讀的能力；
如果讀實例壓力依然很大哈踱，可以在數(shù)據(jù)庫前面加入緩存如 redis荒适，讓請求優(yōu)先從緩存取數(shù)據(jù)減少數(shù)據(jù)庫訪問。
緩存分擔(dān)了部分壓力后开镣，數(shù)據(jù)庫依然是瓶頸刀诬，這個時候就可以考慮分庫分表的方案了，后面會詳細(xì)介紹邪财。
硬件優(yōu)化
硬件成本非常高陕壹，一般來說不可能遇到數(shù)據(jù)庫性能瓶頸就去升級硬件。
在前期業(yè)務(wù)量比較小的時候树埠，升級硬件數(shù)據(jù)庫性能可以得到較大提升糠馆；但是在后期，升級硬件得到的收益就不那么明顯了怎憋。
分庫分表詳解
下面我們以一個商城系統(tǒng)為例逐步講解數(shù)據(jù)庫是如何一步步演進(jìn)又碌。
單應(yīng)用單數(shù)據(jù)庫
在早期創(chuàng)業(yè)階段想做一個商城系統(tǒng)，基本就是一個系統(tǒng)包含多個基礎(chǔ)功能模塊盛霎，最后打包成一個 war 包部署赠橙，這就是典型的單體架構(gòu)應(yīng)用耽装。
商城項目使用單數(shù)據(jù)庫
如上圖愤炸，商城系統(tǒng)包括主頁 Portal 模板、用戶模塊掉奄、訂單模塊规个、庫存模塊等，所有的模塊都共有一個數(shù)據(jù)庫姓建，通常數(shù)據(jù)庫中有非常多的表诞仓。
因為用戶量不大，這樣的架構(gòu)在早期完全適用速兔，開發(fā)者可以拿著 demo到處找（騙）投資人墅拭。
一旦拿到投資人的錢，業(yè)務(wù)就要開始大規(guī)模推廣涣狗，同時系統(tǒng)架構(gòu)也要匹配業(yè)務(wù)的快速發(fā)展谍婉。
多應(yīng)用單數(shù)據(jù)庫
在前期為了搶占市場舒憾，這一套系統(tǒng)不停地迭代更新，代碼量越來越大穗熬，架構(gòu)也變得越來越臃腫镀迂，現(xiàn)在隨著系統(tǒng)訪問壓力逐漸增加，系統(tǒng)拆分就勢在必行了唤蔗。
為了保證業(yè)務(wù)平滑探遵，系統(tǒng)架構(gòu)重構(gòu)也是分了幾個階段進(jìn)行。
第一個階段將商城系統(tǒng)單體架構(gòu)按照功能模塊拆分為子服務(wù)妓柜，比如：Portal 服務(wù)箱季、用戶服務(wù)、訂單服務(wù)棍掐、庫存服務(wù)等规哪。
多應(yīng)用單數(shù)據(jù)庫
如上圖，多個服務(wù)共享一個數(shù)據(jù)庫塌衰，這樣做的目的是底層數(shù)據(jù)庫訪問邏輯可以不用動诉稍，將影響降到最低。
多應(yīng)用多數(shù)據(jù)庫
隨著業(yè)務(wù)推廣力度加大最疆，數(shù)據(jù)庫終于成為了瓶頸杯巨，這個時候多個服務(wù)共享一個數(shù)據(jù)庫基本不可行了。我們需要將每個服務(wù)相關(guān)的表拆出來單獨建立一個數(shù)據(jù)庫努酸，這其實就是“分庫”了服爷。
單數(shù)據(jù)庫的能夠支撐的并發(fā)量是有限的，拆成多個庫可以使服務(wù)間不用競爭获诈，提升服務(wù)的性能仍源。
多應(yīng)用多數(shù)據(jù)庫
如上圖，從一個大的數(shù)據(jù)中分出多個小的數(shù)據(jù)庫舔涎，每個服務(wù)都對應(yīng)一個數(shù)據(jù)庫笼踩，這就是系統(tǒng)發(fā)展到一定階段必要要做的“分庫”操作。
現(xiàn)在非惩鱿樱火的微服務(wù)架構(gòu)也是一樣的嚎于，如果只拆分應(yīng)用不拆分?jǐn)?shù)據(jù)庫，不能解決根本問題挟冠，整個系統(tǒng)也很容易達(dá)到瓶頸于购。
分表
說完了分庫，那什么時候分表呢知染？
如果系統(tǒng)處于高速發(fā)展階段肋僧，拿商城系統(tǒng)來說，一天下單量可能幾十萬，那數(shù)據(jù)庫中的訂單表增長就特別快嫌吠，增長到一定階段數(shù)據(jù)庫查詢效率就會出現(xiàn)明顯下降伪窖。
因此，當(dāng)單表數(shù)據(jù)增量過快居兆，業(yè)界流傳是超過500萬的數(shù)據(jù)量就要考慮分表了覆山。當(dāng)然500萬只是一個經(jīng)驗值，大家可以根據(jù)實際情況做出決策泥栖。
那如何分表呢簇宽？
分表有幾個維度，一是水平切分和垂直切分吧享，二是單庫內(nèi)分表和多庫內(nèi)分表魏割。
水平拆分和垂直拆分
就拿用戶表（user）來說，表中有7個字段：id,name,age,sex,nickname,description钢颂，如果 nickname 和 description 不常用钞它，我們可以將其拆分為另外一張表：用戶詳細(xì)信息表，這樣就由一張用戶表拆分為了用戶基本信息表+用戶詳細(xì)信息表殊鞭，兩張表結(jié)構(gòu)不一樣相互獨立遭垛。但是從這個角度來看垂直拆分并沒有從根本上解決單表數(shù)據(jù)量過大的問題，因此我們還是需要做一次水平拆分操灿。
拆分表
還有一種拆分方法锯仪，比如表中有一萬條數(shù)據(jù)，我們拆分為兩張表趾盐，id 為奇數(shù)的：1庶喜，3，5救鲤，7……放在 user1久窟， id 為偶數(shù)的：2，4本缠，6斥扛，8……放在 user2中，這樣的拆分辦法就是水平拆分了搓茬。
水平拆分的方式也很多犹赖，除了上面說的按照 id 拆表，還可以按照時間維度取拆分卷仑，比如訂單表，可以按每日麸折、每月等進(jìn)行拆分锡凝。
每日表：只存儲當(dāng)天的數(shù)據(jù)。
每月表：可以起一個定時任務(wù)將前一天的數(shù)據(jù)全部遷移到當(dāng)月表垢啼。
歷史表：同樣可以用定時任務(wù)把時間超過 30 天的數(shù)據(jù)遷移到 history表窜锯。
總結(jié)一下水平拆分和垂直拆分的特點：
垂直切分：基于表或字段劃分张肾，表結(jié)構(gòu)不同。
水平切分：基于數(shù)據(jù)劃分锚扎，表結(jié)構(gòu)相同吞瞪，數(shù)據(jù)不同。
單庫內(nèi)拆分和多庫拆分
拿水平拆分為例驾孔，每張表都拆分為了多個子表芍秆，多個子表存在于同一數(shù)據(jù)庫中。比如下面用戶表拆分為用戶1表翠勉、用戶2表妖啥。
單庫拆分
在一個數(shù)據(jù)庫中將一張表拆分為幾個子表在一定程度上可以解決單表查詢性能的問題，但是也會遇到一個問題：單數(shù)據(jù)庫存儲瓶頸对碌。
所以在業(yè)界用的更多的還是將子表拆分到多個數(shù)據(jù)庫中荆虱。比如下圖中，用戶表拆分為兩個子表朽们，兩個子表分別存在于不同的數(shù)據(jù)庫中怀读。
多庫拆分
一句話總結(jié)：分表主要是為了減少單張表的大小，解決單表數(shù)據(jù)量帶來的性能問題骑脱。
分庫分表帶來的復(fù)雜性
既然分庫分表這么好愿吹，那我們是不是在項目初期就應(yīng)該采用這種方案呢？不要激動惜姐，冷靜一下犁跪，分庫分表的確解決了很多問題，但是也給系統(tǒng)帶來了很多復(fù)雜性歹袁，下面簡要說一說坷衍。
（1）跨庫關(guān)聯(lián)查詢
在單庫未拆分表之前，我們可以很方便使用 join 操作關(guān)聯(lián)多張表查詢數(shù)據(jù)条舔，但是經(jīng)過分庫分表后兩張表可能都不在一個數(shù)據(jù)庫中枫耳，如何使用 join 呢？
有幾種方案可以解決：
- 字段冗余：把需要關(guān)聯(lián)的字段放入主表中孟抗，避免 join 操作迁杨；
- 數(shù)據(jù)抽象：通過ETL等將數(shù)據(jù)匯合聚集，生成新的表凄硼；
- 全局表：比如一些基礎(chǔ)表可以在每個數(shù)據(jù)庫中都放一份铅协；
- 應(yīng)用層組裝：將基礎(chǔ)數(shù)據(jù)查出來喧务，通過應(yīng)用程序計算組裝盛卡；
（2）分布式事務(wù)
單數(shù)據(jù)庫可以用本地事務(wù)搞定，使用多數(shù)據(jù)庫就只能通過分布式事務(wù)解決了峡懈。
常用解決方案有：基于可靠消息（MQ）的解決方案、兩階段事務(wù)提交骏全、柔性事務(wù)等苍柏。
（3）排序、分頁姜贡、函數(shù)計算問題
在使用 SQL 時 order by试吁， limit 等關(guān)鍵字需要特殊處理，一般來說采用分片的思路：
先在每個分片上執(zhí)行相應(yīng)的函數(shù)楼咳，然后將各個分片的結(jié)果集進(jìn)行匯總和再次計算熄捍，最終得到結(jié)果。
（4）分布式 ID
如果使用 Mysql 數(shù)據(jù)庫在單庫單表可以使用 id 自增作為主鍵爬橡，分庫分表了之后就不行了治唤，會出現(xiàn)id 重復(fù)。
常用的分布式 ID 解決方案有：
- UUID
- 基于數(shù)據(jù)庫自增單獨維護(hù)一張 ID表
- 號段模式
- Redis 緩存
- 雪花算法（Snowflake）
- 百度uid-generator
- 美團Leaf
- 滴滴Tinyid
這些方案后面會寫文章專門介紹糙申，這里不再展開宾添。
（5）多數(shù)據(jù)源
分庫分表之后可能會面臨從多個數(shù)據(jù)庫或多個子表中獲取數(shù)據(jù)，一般的解決思路有：客戶端適配和代理層適配柜裸。
業(yè)界常用的中間件有：
- shardingsphere（前身 sharding-jdbc）
- Mycat
總結(jié)
如果出現(xiàn)數(shù)據(jù)庫問題不要著急分庫分表缕陕，先看一下使用常規(guī)手段是否能夠解決。
分庫分表會給系統(tǒng)帶來巨大的復(fù)雜性疙挺，不是萬不得已建議不要提前使用扛邑。作為系統(tǒng)架構(gòu)師可以讓系統(tǒng)靈活性和可擴展性強，但是不要過度設(shè)計和超前設(shè)計铐然。在這一點上蔬崩，架構(gòu)師一定要有前瞻性，提前做好預(yù)判搀暑。大家學(xué)會了嗎沥阳？
版權(quán)所有，轉(zhuǎn)載請注明出去：https://mp.weixin.qq.com/s/AB5yI6NpUOTiqqmyoUqJNA
