記得，如果有人問你做數據庫優化最有效的方式是什麼？
SQL優化、分佈式集羣、分庫分表！幹就完了~
但上來就考慮分庫分表真的合適麼，你對分庫分表又理解多少呢？什麼時候分？有幾種分法兒？
首先我們要知道分庫、分表都是幹啥的，本文主角還是我們的MySQL爲第一視角。首先從字面意思來看：
分庫：
由單個數據庫實例拆分成多個數據庫實例，將數據分佈到多個數據庫實例中。
分表：
由單張表拆分成多張表，將數據劃分到多張表內。
要知道，對於大型互聯網項目，數據量級可能不是我們能想到的，每日新增數據量過千萬是常有的事兒，想靠單臺MySQL服務器是不現實的。你項羽在牛B，也頂不住四個隊友掛機啊！！項羽：？？？
隨着業務數據量和網站QPS日益增高，對數據庫壓力也越來越大，單機版數據庫很快會到達存儲和併發瓶頸，就需要做數據庫性能方面的優化，分庫分表採取的是分而治之的策略，分庫目的是減輕單臺MySQL實例存儲壓力及可擴展性，而分表是解決單張表數據過大以後查詢的瓶頸問題，坦白說，這些問題也是所有關係型數據庫的“硬傷”。
今天我們就基於常見分庫、分表的策略方式以及場景，來搞清楚我們到底啥時候用的到。常用策略包括：垂直分表、水平分表、垂直分庫、水平分庫。
一、樸實無華的 - 分表
1、垂直分表
垂直分表，或者叫豎着切表，是不是感受到該策略是以字段爲依據的！主要按照字段的活躍性、字段長度，將表中字段拆分到不同的表（主表和擴展表）中。
特點：
每個表的結構都不一樣；
每個表的數據也不一樣，有一個關聯字段，一般是主鍵或外鍵，用於關聯兄弟表數據；
所有兄弟表的並集是該表的全量數據；
場景：
有幾個字段屬於熱點字段，更新頻率很高，要把這些字段單獨切到一張表裏，不然innodb行鎖很噁心的，鎖死你呀，如用戶表裏的餘額字段？不，我的餘額就很穩定，一直是0。。
有大字段，如text，存儲壓力很大，畢竟innodb數據和索引是同一個文件；同時，我又喜歡用SELECT *，你懂得，這磁盤IO消耗的，跟玩兒似的，誰都扛不住的。
有明顯的業務區分，或表結構設計時字段冗餘；有些小夥伴看到第一點時，就發現陳哈哈是個菜雞，用戶表怎麼會有餘額字段？明顯有問題啊！趕緊先到評論區噴陳哈哈一波，然後笑嘻嘻的發現原來是個小尾巴，真不要臉是吧。。是的，因此不同業務我們要把具體字段拆開，這樣纔有利於業務後續擴展哦。
2、水平分表
水平分表，也叫“橫着切”。。以行數據爲依據進行切分，一般按照某列的自容進行切分。
如手機號表，我們可以通過前兩位或前三位進行切分，如131、132、133 → phone_131、phone_132、phone_133，手機號有11位（100億），量大是很正常的事兒，這年頭誰家老頭老太太每個手機呢是吧。這樣切就把一張大表切成了好幾十張小表，數據量不就下來了。
有同學就問了那我怎麼知道我這手機號查哪個表呢？一看你就沒認真看前兩行標紅的點，爲啥標紅嘞？比如我查13100001111，那我截取前三位，動態拼接到查詢的表名上，就行了。
特點：
每個表的結構都一樣；
每個表的數據都不一樣，沒有交集；
所有表的並集是該表的全量數據；
場景：
單表的數據量過大或增長速度很快，已經影響或即將會影響SQL查詢效率，加重了CPU負擔，提前到達瓶頸。記得水平分表越早越好，別問我爲什麼。。
二、花裏胡哨的 - 分庫
需要你注意的是，傳統的分庫和我們熟悉的集羣、主從複製可不是一個事兒；多節點集羣是將一個庫複製成N個庫，從而通過讀寫分離實現多個MySQL服務的負載均衡，實際是圍繞一個庫來搞的，這個庫稱爲Master主庫。
而分庫就不同了，分庫是將這個主庫一分爲N，比如一分爲二，然後針對這兩個主庫，再配置2N個從庫節點。
1、垂直分庫
縱向切庫，太經典的切分方式，基於表進行切分，通常是把新的業務模塊或集成公共模塊拆分出去，比如我們最熟悉的單點登錄、鑑權模塊。熟悉的味道，記得有一次我把一些沒用的表切到一個性能很好的服務器中，這服務器我專門用來學習，後來也不知被哪個狗腿子告密了~
特點：
每個庫的表都不一樣；
表不一樣，數據就更不一樣了~ 沒有任何交集；
每個庫相對獨立，模塊化；
場景：
可以抽象出單獨的業務模塊時，可以抽象出公共區時（如字典、公共時間、公共配置等），或者想有一臺屬於自己的服務器時？
2、水平分庫
以行數據爲依據，將一個庫中的數據拆分到多個庫中。大型分表體驗一下？坦白說這種策略並不實用，因爲會對後臺開發很不友好，有很多坑，不建議採用，理解即可。
特點：
每個庫的結構都一樣；
每個庫的數據都不一樣，沒有交集；
所有庫的並集是全量數據；
場景：
系統絕對併發量上來了，CPU內存壓力大。分表難以根本上解決量的問題，並且還沒有明顯的業務歸屬來垂直分庫，主庫磁盤接近飽和。
總結
本文就到這裏，希望你學廢了！其實，在實際工作中，我們在選擇分庫分表策略前，想到的應該是從緩存、讀寫分離、SQL優化等方面，因爲這些能夠更直接、代價更小的解決問題。
要記住動表就是動根本，你永遠不知道這張表後面會連帶多少歷史遺留問題，如果是個很大型的項目，遇到些問題你就跟經理提議要分庫分表，小心被呼死~
原文鏈接：https://blog.csdn.net/qq_39390545/article/details/116248222
版權聲明：本文爲CSDN博主「_陳哈哈」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。
近期熱文推薦：
1.1,000+ 道 Java面試題及答案整理(2021最新版)
2.終於靠開源項目弄到 IntelliJ IDEA 激活碼了，真香！
3.阿里 Mock 工具正式開源，幹掉市面上所有 Mock 工具！
4.Spring Cloud 2020.0.0 正式發佈，全新顛覆性版本！
覺得不錯，別忘了隨手點贊+轉發哦！