小伙伴想精準查找自己想看的MySQL文章？喏 → MySQL江湖路 | 專欄目錄
??記得，如果有人問你做資料庫優化最有效的方式是什么？
SQL優化、分布式集群、分庫分表！干就完了~ 但上來就考慮分庫分表真的合適么，你對分庫分表又理解多少呢？什么時候分？有幾種分法兒？
??別想了，快上車！哈哥帶你捋一下分庫分表的額各種玩兒法~記得收藏
目錄
- 一、樸實無華的 - 分表
- 1、垂直分表
- 2、水平分表
- 二、花里胡哨的 - 分庫
- 3、垂直分庫
- 4、水平分庫
- 總結
??首先我們要知道分庫、分表都是干啥的，本文主角還是我們的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負擔，提前到達瓶頸，記得水平分表越早越好，別問我為什么，，
??你要有興趣試一試，就關注我，讓csdn研發同學給我的粉絲們分個表哈哈，，算了，別做夢了，忘了你是個菜狗了么~
二、花里胡哨的 - 分庫
??需要你注意的是，傳統的分庫和我們熟悉的集群、主從復制可不是一個事兒；多節點集群是將一個庫復制成N個庫，從而通過讀寫分離實作多個MySQL服務的負載均衡，實際是圍繞一個庫來搞的，這個庫稱為Master主庫，而分庫就不同了，分庫是將這個主庫一分為N，比如一分為二，然后針對這兩個主庫，再配置2N個從庫節點，
3、垂直分庫
??縱向切庫，太經典的切分方式，基于表進行切分，通常是把新的業務模塊或集成公共模塊拆分出去，比如我們最熟悉的單點登錄、鑒權模塊，熟悉的味道，記得有一次我把一些沒用的表切到一個性能很好的服務器中，這服務器我專門用來學習，后來也不知被哪個狗腿子告密了~ 我**你個**，有種站出來，你個**東西😅😅，
特點：
- 每個庫的表都不一樣；
- 表不一樣，資料就更不一樣了~ 沒有任何交集；
- 每個庫相對獨立，模塊化
場景：可以抽象出單獨的業務模塊時，可以抽象出公共區時（如字典、公共時間、公共配置等），或者想有一臺屬于自己的服務器時？
4、水平分庫
??以行資料為依據，將一個庫中的資料拆分到多個庫中，大型分表體驗一下？坦白說這種策略并不實用，因為會對后臺開發很不友好，有很多坑，不建議采用，理解即可，
特點：
- 每個庫的結構都一樣；
- 每個庫的資料都不一樣，沒有交集；
- 所有庫的并集是全量資料；
場景：系統絕對并發量上來了，CPU記憶體壓力大，分表難以根本上解決量的問題，并且還沒有明顯的業務歸屬來垂直分庫，主庫磁盤接近飽和，
總結
??本文就到這里，希望你學廢了！其實，在實際作業中，我們在選擇分庫分表策略前，想到的應該是從快取、讀寫分離、SQL優化等方面，因為這些能夠更直接、代價更小的解決問題，要記住動表就是動根本，你永遠不知道這張表后面會連帶多少歷史遺留問題，如果是個很大型的專案，遇到些問題你就跟經理提議要分庫分表，小心被呼死~
??好了，多了就不說了，我勸你耗子尾汁，但推薦你關注我，因為我會讓你在快樂中學會很多東西！
MySQL系列文章匯總與《MySQL江湖路 | 專欄目錄》
往期熱門MySQL系列文章：
- 原創 | MySQL中特別實用的幾種SQL陳述句送給大家
- 原創 | SQL優化最干貨總結 - MySQL（2020最新版）
- 原創 | 為什么大家都說SELECT * 效率低
- 原創 | 面試讓HR都能聽懂的MySQL鎖機制，歡聲笑語中搞懂MySQL鎖
- 原創 | MySQL中的 utf8 并不是真正的UTF-8編碼 ! !
- 原創 | MySQL資料中有很多換行符和回車符！！該咋辦？
- 原創 | delete后加 limit是個好習慣么
- 原創 | MySQL慢查詢，一口從天而降的鍋！
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/281633.html
標籤：其他