單表千萬級數據遷移實踐方案-乞丐版，不使用大數據平臺

1、現狀

mysql下，某business單表已近2000萬且還在持續增長中,存在多個索引，有較高的查詢壓力。現業務端使用guava cache攔了一道，還能頂得住，可是後臺管理系統的全量數據的分頁排序查詢比較慢，且未來會愈來愈慢。

2、目標

 業務端+admin查詢都快。

3、解決方案

1.基於實際狀況（你們必定要根據實際狀況來），把數據庫拆爲三個，以下：

1. 熱數據(老表)：提供CURD操做，事務加鎖等等，最大限度的不用更改原代碼。
2. 半年內數據（history）：只提供查詢業務。
3. 半年以前數據(backup)：歸檔，不提供業務查詢，只支持手動查庫(已跟產品溝通好)。

2.數據遷移，採用公司統一任務調度平臺，註冊任務後調度執行，自帶WEB管理頁面。支持暫停、恢復、執行計劃、日誌查詢。

3.因爲歷史數據過千萬，須要上線前進行一次手動遷移，初始化數據

            1）history表保存：7天~半年，非進行狀態的數據。

            2）backup表保存：半年前的，非進行狀態的數據。

            3）刪除business表中，7天前的，非進行狀態的數據。

4. 後續天天凌晨定時任務遷移數據（遷移時注意：保證ID一致  ）

            business-->history      >7天，非進行狀態的數據。

            history-->backup   >半年，非進行狀態的數據。

5.admin切到從庫讀。主從分離,避免從庫讀全量數據，致使業務端查詢緩慢。

4、採坑

1.千萬級帶索引刪除記錄，記得不能一次性直接delete,能夠根據建立時間來，一次刪除百萬級數據，多分幾回刪除。不然容易出現假死，慢查詢，kill不掉執行sql.

2.注意初始化數據時候，可能當天屢次執行，因此加上修改時間在當天前的，這樣屢次執行，不會出現數據重複。

3.寫批量插入sql時，

1）不要用函數：sql中使用函數極端消耗時間。

2）不要用#，要用$：避免再次編譯消耗時間，這裏不用怕什麼sql注入，內部接口。

 1 <insert id="transferTradingOrderByIds">
 2     insert into ${toTableName} (<include refid="Base_Column_List"/>)
 3     select <include refid="Base_Column_List"/>
 4     from ${fromTableName}
 5     <where>
 6         id in
 7         <foreach collection="transferTradingOrderIds" item="id" separator="," open="(" close=")">
 8             ${id}
 9         </foreach>
10     </where>
11 </insert>

5、結果

熱表數據:一百萬內，增刪改查極快。

歷史數據:一千萬內，查詢快。

歸檔數據：千萬級以上，慢，可是業務不調用。