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

一、現狀

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

二、目標

 業務端+admin查詢都快。

三、解決方案

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切到從庫讀。主從分離,避免從庫讀全量數據，導致業務端查詢緩慢。

四、採坑

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

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

3.寫批量插入sql時，

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

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

<insert id="transferTradingOrderByIds">
    insert into ${toTableName} (<include refid="Base_Column_List"/>)
    select <include refid="Base_Column_List"/>
    from ${fromTableName}
    <where>
        id in
        <foreach collection="transferTradingOrderIds" item="id" separator="," open="(" close=")">
            ${id}
        </foreach>
    </where>
</insert>

五、結果

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

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

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