在實際業務中，隨著時間推移，訂單量持續增長，若未及時進行數據治理，會造成數據庫膨脹、查詢緩慢、性能下降等問題。為了實現數據分層管理和系統高性能運行，我們在項目中采用了“冷熱數據分離 + 分批遷移 + 數據清理”的綜合方案。

本文將圍繞以下幾個核心點展開：

• ? 為什么要進行冷熱數據分離？

• ? 如何用分批分頁遷移歷史訂單？

• ? 如何在遷移完成后安全刪除同步表數據？

---

🔍 一、為什么要冷熱數據分離？

隨著訂單業務增長，即使采用分庫分表，數據總量依舊快速膨脹。對歷史訂單的訪問熱度遠遠低于進行中訂單。因此我們有必要：

• 將熱數據（15日內未完成訂單）保存在主訂單表，供高頻訪問；

• 將冷數據（15日前完成訂單）歸檔到歷史訂單表，減少主庫壓力；

• 提升整體系統性能和數據庫查詢效率。

?注意：雖然阿里云 OSS 等對象存儲價格低，但不支持復雜查詢操作（如 SQL 聚合、分頁、統計），無法滿足用戶和運營的歷史訂單檢索與分析需求，因此必須選擇支持查詢的數據庫，如分布式數據庫 TiDB。

---

🔄 二、分批分頁遷移：保證性能和穩定性

? 核心思想：

• 一次遷移 1000 條數據，控制內存和 SQL 壓力；

• 使用 offset + limit 實現分頁；

• 按天定時遷移前一天完成的訂單；

• 保證數據完整性，支持失敗重試。

🔧 遷移代碼示例：

@Override
public void migrate() {log.debug("歷史訂單遷移開始...");int offset = 0, perNum = 1000;LocalDateTime startTime = DateUtils.getDayStartTime(DateUtils.now().minusDays(1));LocalDateTime endTime = DateUtils.getDayEndTime(DateUtils.now().minusDays(1));Integer total = historyOrdersSyncService.countBySortTime(startTime, endTime);if (total <= 0) return;while (offset < total) {baseMapper.migrate(startTime, endTime, offset, perNum);offset += perNum;}log.debug("歷史訂單遷移結束。");
}

---

🧹 三、遷移完成后，如何安全刪除同步表數據？

在實現冷熱分離過程中，我們使用中間同步表（用于異步遷移），為避免數據重復、節省空間，遷移完成后需及時刪除同步表中已處理的數據。

為了防止誤刪或未遷移完全，我們加入了刪除前校驗機制。

🛡 刪除邏輯及校驗示例：

@Override
public void deleteMigrated() {LocalDateTime startTime = DateUtils.getDayStartTime(DateUtils.now().minusDays(1));LocalDateTime endTime = DateUtils.getDayEndTime(DateUtils.now().minusDays(1));// 1. 檢查是否存在可刪除數據Integer totalOfDelete = historyOrdersServeSyncService.countBySortTime(startTime, endTime);if (totalOfDelete <= 0) {log.debug("無遷移服務單數據需要刪除");return;}// 2. 校驗遷移是否完整Integer totalMigrated = lambdaQuery().between(HistoryOrdersServe::getSortTime, startTime, endTime).count();if (NumberUtils.null2Zero(totalMigrated) <= 0 || totalOfDelete > totalMigrated) {log.error("服務單未完全遷移，同步數據刪除失敗");return;}// 3. 刪除同步表中已遷移數據historyOrdersServeSyncService.deleteBySortTime(startTime, endTime);
}

?? 刪除保障機制：

校驗項	描述
數量比對	同步表中“待刪除數量”必須 ≤ 歷史表中“已遷移數量”
分時間段	刪除與遷移都按天執行，避免大批量誤刪
日志記錄	失敗及時報警，便于排查

---

🧠 四、架構補充說明

🔗 為什么不直接刪除主表而使用同步表？

• 避免直接影響主庫性能；

• 支持異步、可重試的遷移策略；

• 可配合 binlog + MQ 實現實時同步機制。

💽 使用 TiDB 存儲歷史數據的優勢：

• 支持 MySQL 協議，易于對接；

• 同時支持 OLTP 和 OLAP 查詢（HTAP）；

• 分布式架構，水平擴展，適合大規模數據歸檔。

---

? 總結

歷史訂單遷移不僅是技術優化，更是數據治理的關鍵環節。

本方案通過以下幾個方面保證效率與穩定：

• 使用分頁遷移，避免性能瓶頸；

• 同步表中間態設計，解耦遷移流程；

• 增加數據完整性校驗與清理邏輯；

• 結合 定時任務 實現每日自動遷移與清理；

• 歷史數據存儲選擇 支持 SQL 的分布式數據庫（如 TiDB），滿足查詢與統計需求。