前提:

1.原有庫是mysql數(shù)據(jù)庫,已經(jīng)根據(jù)用戶pin分片
2.每片是一主兩從
3.主表已經(jīng)分過表了
4.數(shù)據(jù)庫所在服務(wù)器為4C8G
5.庫中數(shù)據(jù)量已經(jīng)超過千萬,而且以每天3萬多的數(shù)據(jù)持續(xù)增長,將來每天或許會更多
6.庫內(nèi)數(shù)據(jù)為訂單數(shù)據(jù)，每時(shí)每刻都有新的訂單產(chǎn)生，每個(gè)訂單都要經(jīng)歷多個(gè)狀態(tài)的變化，最終變成完成狀態(tài)，每次變化狀態(tài)，都會對數(shù)據(jù)庫進(jìn)行修改

正題：

現(xiàn)在這樣的數(shù)據(jù)庫，其實(shí)是完全可以支持現(xiàn)有業(yè)務(wù)，但考慮到以后隨著數(shù)據(jù)量的日益增長，每次查詢都要在千萬數(shù)據(jù)中查找，但其實(shí)大部分查詢，都是查最近的數(shù)據(jù)，歷史數(shù)據(jù)幾乎不查詢，基于這個(gè)條件，就考慮到可以做個(gè)分庫，也就是冷熱分離。

所謂冷熱分離，網(wǎng)上有很多說法，而我之所以做冷熱分離，最終目的，就是為了將經(jīng)常使用查詢的數(shù)據(jù)放在生產(chǎn)庫中，而查詢不多的歷史數(shù)據(jù)就放在歷史庫中，這樣既可以保證數(shù)據(jù)的完整，也可以減輕生產(chǎn)庫的壓力。

既然有這樣的分庫查詢，那就涉及到兩個(gè)庫的數(shù)據(jù)同步（這里叫生產(chǎn)庫和歷史庫）
生產(chǎn)庫放的是熱數(shù)據(jù)，歷史課放冷數(shù)據(jù)

正常下單后，訂單數(shù)據(jù)還是添加到生產(chǎn)庫中，但是每次數(shù)據(jù)在生產(chǎn)庫的變化，都會多發(fā)一個(gè)mq出去,mq中帶有這個(gè)訂單數(shù)據(jù)的唯一主鍵和訂單所改變的狀態(tài)

歷史庫接收到這個(gè)mq,再反查生產(chǎn)庫，獲得這條數(shù)據(jù)，然后在歷史庫做相應(yīng)的狀態(tài)更改，這樣就可以保證歷史庫和生產(chǎn)庫的數(shù)據(jù)統(tǒng)一

如下圖：

---

對于生產(chǎn)庫，原則上只保留500萬左右的熱數(shù)據(jù)，其余歷史數(shù)據(jù)，全部放在歷史庫，這樣又會有兩個(gè)重點(diǎn)：數(shù)據(jù)遷移和多數(shù)據(jù)源的查詢

1.數(shù)據(jù)遷移

以下提供幾種數(shù)據(jù)遷移的思路
1.1.執(zhí)行一個(gè)job,定時(shí)每天凌晨開始自動遷移，每次遷移若干條，這樣就會在不知不覺中將數(shù)據(jù)遷移完，這樣最保險(xiǎn)，但不是效率最高
1.2.直接用一個(gè)線程池，最多開五個(gè)線程（具體能開幾個(gè)，看自己的機(jī)器性能），然后每個(gè)線程每次只跑一天的量，這樣其實(shí)也是很快的

2.多數(shù)據(jù)源的查詢

有了兩個(gè)數(shù)據(jù)源，那么什么時(shí)候查生產(chǎn)庫，什么時(shí)候查歷史庫就是需要考慮的一個(gè)問題，我這邊完全是業(yè)務(wù)方面的區(qū)分，這里只提一嘴，供參考
2.1.針對單條數(shù)據(jù)的查詢，單條數(shù)據(jù)的查詢一般發(fā)生在剛剛下單后，所以優(yōu)先查詢生產(chǎn)庫，生產(chǎn)庫沒有，再去查詢歷史庫。
2.2.針對某一時(shí)間段內(nèi)，多條數(shù)據(jù)查詢list,這里我們可以預(yù)先定義一個(gè)分割線，這個(gè)分割線是一個(gè)日期，這個(gè)日期就是生產(chǎn)庫最早一條數(shù)據(jù)的日期，有了這個(gè)分割線，那我們只需要拿要查詢的日期區(qū)間和這個(gè)分割線做比較，即可確定
2.3.針對多個(gè)分散訂單的查詢list,理論上沒有任何規(guī)律，但是由于歷史數(shù)據(jù)發(fā)現(xiàn)，這種情況一般有數(shù)量不多，數(shù)據(jù)多在近期的特征，所以還是優(yōu)先查詢生產(chǎn)庫，查不到再查詢歷史庫

思考

這個(gè)冷熱分離的好處，就是將不常用的數(shù)據(jù)放在歷史庫中，當(dāng)然，這個(gè)歷史庫也可以是多個(gè)，也就是一個(gè)生產(chǎn)庫，多個(gè)歷史庫，每個(gè)歷史庫都存放某一時(shí)間段的數(shù)據(jù)

擴(kuò)展

作為思考，如果以后每天的數(shù)據(jù)量都很大，我將考慮在數(shù)據(jù)庫之前加一層緩存，比如用redis等非關(guān)系型數(shù)據(jù)庫,或者用es，因?yàn)橐郧耙矅L試過用這樣的方式來緩解數(shù)據(jù)庫的壓力，但發(fā)現(xiàn)會存在低幾率的數(shù)據(jù)丟失，所以在這些又會涉及到數(shù)據(jù)的準(zhǔn)確性，數(shù)據(jù)的即時(shí)同步將會是一個(gè)很大的挑戰(zhàn)，但這應(yīng)該是現(xiàn)有技術(shù)中，對于上億級別的數(shù)據(jù)即使查詢，比較好的方式了

總結(jié)

以上是生活随笔為你收集整理的[数据库]-----记一次mysql分库的操作（冷热分离）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。