這四種情況下，才是考慮分庫分表的時候！

1、《往期精選優(yōu)秀博文都在這里了！》
2、線上 4 臺機(jī)器同一時間全部 OOM，到底發(fā)生了什么？
3、爽啊！Intellij IDEA 神器居然還藏著這些實用小技巧 ！
4、這樣調(diào)優(yōu)：讓你的 IDEA 快到飛起來，效率真高！
5、JDK 16 即將發(fā)布，新特性速覽！
來源：https://juejin.im/post/6844903992909103117

數(shù)據(jù)庫瓶頸

IO瓶頸

• 第一種：磁盤讀IO瓶頸，熱點數(shù)據(jù)太多，數(shù)據(jù)庫緩存放不下，每次查詢會產(chǎn)生大量的IO，降低查詢速度->分庫和垂直分表
• 第二種：網(wǎng)絡(luò)IO瓶頸，請求的數(shù)據(jù)太多，網(wǎng)絡(luò)帶寬不夠 ->分庫

CPU瓶頸

• 第一種：SQl問題：如SQL中包含join,group by, order by，非索引字段條件查詢等，增加CPU運算的操作->SQL優(yōu)化，建立合適的索引，在業(yè)務(wù)Service層進(jìn)行業(yè)務(wù)計算。
• 第二種：單表數(shù)據(jù)量太大，查詢時掃描的行太多，SQl效率低，增加CPU運算的操作。->水平分表。

水平分庫

• 1、概念：以字段為依據(jù)，按照一定策略（hash、range等），將一個庫中的數(shù)據(jù)拆分到多個庫中。
• 2、結(jié)果：
• 每個庫的結(jié)構(gòu)都一樣
• 每個庫中的數(shù)據(jù)不一樣，沒有交集
• 所有庫的數(shù)據(jù)并集是全量數(shù)據(jù)
• 3、場景：系統(tǒng)絕對并發(fā)量上來了，分表難以根本上解決問題，并且還沒有明顯的業(yè)務(wù)歸屬來垂直分庫的情況下。
• 4、分析：庫多了，io和cpu的壓力自然可以成倍緩解

水平分表

• 1、概念：以字段為依據(jù)，按照一定策略（hash、range等），講一個表中的數(shù)據(jù)拆分到多個表中。
• 2、結(jié)果：
• 每個表的結(jié)構(gòu)都一樣
• 每個表的數(shù)據(jù)不一樣，沒有交集，所有表的并集是全量數(shù)據(jù)。
• 3、場景：系統(tǒng)絕對并發(fā)量沒有上來，只是單表的數(shù)據(jù)量太多，影響了SQL效率，加重了CPU負(fù)擔(dān)，以至于成為瓶頸，可以考慮水平分表。
• 4、分析：單表的數(shù)據(jù)量少了，單次執(zhí)行SQL執(zhí)行效率高了，自然減輕了CPU的負(fù)擔(dān)。

垂直分庫

• 1、概念：以表為依據(jù)，按照業(yè)務(wù)歸屬不同，將不同的表拆分到不同的庫中。
• 2、結(jié)果：
• 每個庫的結(jié)構(gòu)都不一樣
• 每個庫的數(shù)據(jù)也不一樣，沒有交集
• 所有庫的并集是全量數(shù)據(jù)
• 3、場景：系統(tǒng)絕對并發(fā)量上來了，并且可以抽象出單獨的業(yè)務(wù)模塊的情況下。
• 4、分析：到這一步，基本上就可以服務(wù)化了。例如：隨著業(yè)務(wù)的發(fā)展，一些公用的配置表、字典表等越來越多，這時可以將這些表拆到單獨的庫中，甚至可以服務(wù)化。再者，隨著業(yè)務(wù)的發(fā)展孵化出了一套業(yè)務(wù)模式，這時可以將相關(guān)的表拆到單獨的庫中，甚至可以服務(wù)化。

垂直分表

• 1、概念：以字段為依據(jù)，按照字段的活躍性，將表中字段拆到不同的表中（主表和擴(kuò)展表）。
• 2、結(jié)果：
• 每個表的結(jié)構(gòu)不一樣。
• 每個表的數(shù)據(jù)也不一樣，一般來說，每個表的字段至少有一列交集，一般是主鍵，用于關(guān)聯(lián)數(shù)據(jù)。
• 所有表的并集是全量數(shù)據(jù)。
• 3、場景：系統(tǒng)絕對并發(fā)量并沒有上來，表的記錄并不多，但是字段多，并且熱點數(shù)據(jù)和非熱點數(shù)據(jù)在一起，單行數(shù)據(jù)所需的存儲空間較大，以至于數(shù)據(jù)庫緩存的數(shù)據(jù)行減少，查詢時回去讀磁盤數(shù)據(jù)產(chǎn)生大量隨機(jī)讀IO，產(chǎn)生IO瓶頸。
• 4、分析：可以用列表頁和詳情頁來幫助理解。垂直分表的拆分原則是將熱點數(shù)據(jù)（可能經(jīng)常會查詢的數(shù)據(jù)）放在一起作為主表，非熱點數(shù)據(jù)放在一起作為擴(kuò)展表，這樣更多的熱點數(shù)據(jù)就能被緩存下來，進(jìn)而減少了隨機(jī)讀IO。拆了之后，要想獲取全部數(shù)據(jù)就需要關(guān)聯(lián)兩個表來取數(shù)據(jù)。

分庫分表工具

• sharding-jdbc（當(dāng)當(dāng)）
• TSharding（蘑菇街）
• Atlas（奇虎360）
• Cobar（阿里巴巴）
• MyCAT（基于Cobar）
• Oceanus（58同城）
• Vitess（谷歌） 各種工具的利弊自查

分庫分表帶來的問題

需要先在不同的分片節(jié)點中將數(shù)據(jù)進(jìn)行排序并返回，然后將不同分片返回的結(jié)果集進(jìn)行匯總和再次排序，最終返回給用戶 如下圖：上圖只是取第一頁的數(shù)據(jù)，對性能影響還不是很大。但是如果取得頁數(shù)很大，情況就變得復(fù)雜的多，因為各分片節(jié)點中的數(shù)據(jù)可能是隨機(jī)的，為了排序的準(zhǔn)確性，需要將所有節(jié)點的前N頁數(shù)據(jù)都排序好做合并，最后再進(jìn)行整體排序，這樣的操作很耗費CPU和內(nèi)存資源，所以頁數(shù)越大，系統(tǒng)性能就會越差。

????CREATE?TABLE?`sequence`?(??
??????`id`?bigint(20)?unsigned?NOT?NULL?auto_increment,??
??????`stub`?char(1)?NOT?NULL?default?'',??
??????PRIMARY?KEY??(`id`),??
??????UNIQUE?KEY?`stub`?(`stub`)??
????)?ENGINE=MyISAM;

????REPLACE?INTO?sequence?(stub)?VALUES?('a');??
????SELECT?1561439;??

Snowflake分布式自增ID算法

Twitter的snowfalke算法解決了分布式系統(tǒng)生成全局ID的需求，生成64位Long型數(shù)字，組成部分：

• 第一位未使用
• 接下來的41位是毫秒級時間，41位的長度可以表示69年的時間
• 5位datacenterId,5位workerId。10位長度最多支持部署1024個節(jié)點
• 最后12位是毫秒內(nèi)計數(shù)，12位的計數(shù)順序號支持每個節(jié)點每毫秒產(chǎn)生4096個ID序列。

數(shù)據(jù)遷移、擴(kuò)容問題

什么時候考慮分庫分表

• 能不分就不分

• 數(shù)據(jù)量過大，正常運維影響業(yè)務(wù)訪問

• 隨著業(yè)務(wù)發(fā)展，需要對某些字段垂直拆分

• 數(shù)據(jù)量快速增長

往期熱門文章：
1、《歷史文章分類導(dǎo)讀列表！精選優(yōu)秀博文都在這里了！》
2、萬億級數(shù)據(jù)應(yīng)該怎么遷移？
3、從應(yīng)用到底層 36張圖帶你進(jìn)入Redis世界
4、寫代碼有這16個好習(xí)慣，可以減少80%非業(yè)務(wù)的bug
5、順豐快遞：請簽收MySQL靈魂十連
6、一個基于SpringBoot + MyBatis + Vue的代碼生成器
7、Redis 分布式鎖使用不當(dāng)，超賣了100瓶飛天茅臺！?。?/a>
8、如何設(shè)計訂單系統(tǒng)？這篇寫得太好了！
9、如果MySQL磁盤滿了，會發(fā)生什么？還真被我遇到了！
10、阿里開源的27個項目，值得收藏！