前提:

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

正題：

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

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

既然有這樣的分庫查詢，那就涉及到兩個庫的數據同步（這里叫生產庫和歷史庫）
生產庫放的是熱數據，歷史課放冷數據

正常下單后，訂單數據還是添加到生產庫中，但是每次數據在生產庫的變化，都會多發一個mq出去,mq中帶有這個訂單數據的唯一主鍵和訂單所改變的狀態

歷史庫接收到這個mq,再反查生產庫，獲得這條數據，然后在歷史庫做相應的狀態更改，這樣就可以保證歷史庫和生產庫的數據統一

如下圖：

---

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

1.數據遷移

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

2.多數據源的查詢

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

思考

這個冷熱分離的好處，就是將不常用的數據放在歷史庫中，當然，這個歷史庫也可以是多個，也就是一個生產庫，多個歷史庫，每個歷史庫都存放某一時間段的數據

擴展

作為思考，如果以后每天的數據量都很大，我將考慮在數據庫之前加一層緩存，比如用redis等非關系型數據庫,或者用es，因為以前也嘗試過用這樣的方式來緩解數據庫的壓力，但發現會存在低幾率的數據丟失，所以在這些又會涉及到數據的準確性，數據的即時同步將會是一個很大的挑戰，但這應該是現有技術中，對于上億級別的數據即使查詢，比較好的方式了

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。