千萬級數據遷移與分表的技術方案
本篇文章主要講解在年增長數據量爲千萬級的一個企業級處理方案。
本文是按照某個企業的實際情況進行的劃分，每個企業實際業務不同，技術架構也不同，實際應用時，請根據自己企業實際情況進行。文章僅供參考。
按照千萬級這個數據量，只進行水平分表，是完全能夠滿足劃分範圍的實時查詢需要的。
另外，爲了再提高些性能，將熱點數據做個緩存即可。
關於一些交易相關的，建議訂單表的訂單號32位設置：yyyyMMddHHmmssSSS+UUID轉10位字符生成+（5位分佈式增長數字，初始10001，超過5位數字最大範圍從10001重新計數），如果訂單號是這種方式，則可以將前面15位數字作爲下單的時間範圍劃分，並且對於對賬有很大幫助。
另外，每個表一定得有一個自增ID，當頁數較大，分頁查詢時，自增ID的存在可以極大提高查詢的性能。
如訂單號中並沒有時間的標識，可以取訂單創建時間/訂單的交易時間字段。
選擇一種比較好的分片方式，在這裏按照訂單創建時間的維度進行劃分。
https://chenhx.blog.csdn.net/article/details/104951786
爲什麼不選擇訂單號取模的方式進行
- 訂單的查詢絕大多數是通過訂單時間進行查詢
- 使用取模的方式進行分片會造成後期水平擴展麻煩，給後期增加了不必要的麻煩
- 按照創建時間維度分片的缺點，使用訂單號取模分片一樣會有，非分片維度的查詢問題，所有的分庫分表都會有這種問題存在，基本上都需要引入映射冗餘才能進行解決。
所以選擇按照時間範圍進行一個分庫。
假設是一年1000w的數據，MySQL官方文檔說單表500W-800W，性能才逐漸下降，但是在實際應用中，MySQL可能在單表300W條左右的記錄後性能就開始慢慢下降，當然500W以內的單表數據，MySQL查詢性能都是比