# 演示表
DROP TABLE IF EXISTS `biz_order`;
CREATE TABLE `biz_order`  (
  `id` bigint NOT NULL AUTO_INCREMENT COMMENT 'id',
  `order_no` varchar(20) NOT NULL COMMENT '訂單編號',
  `order_status` tinyint NOT NULL COMMENT '訂單狀態(tài)(1:成功 2:失敗 3:支付中)',
  ..... 省略N個字段
  `gmt_create` datetime NOT NULL COMMENT '創(chuàng)建時間',
  PRIMARY KEY (`id`) USING BTREE
) ENGINE = InnoDB CHARACTER SET = utf8mb4 COLLATE = utf8mb4_0900_ai_ci COMMENT = '訂單表' ROW_FORMAT = Dynamic;
# 這里非常重要，歷史表必需與原表結構保持一致，即使可能原表上會有N個索引影響遷移的性能
CREATE TABLE biz_order_history LIKE biz_order;

# 歸檔日志記錄表
DROP TABLE IF EXISTS `biz_archive_log`;
CREATE TABLE `biz_archive_log`  (
  `id` bigint NOT NULL AUTO_INCREMENT COMMENT '自增id',
  `src_table` varchar(100) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci NULL DEFAULT NULL COMMENT '歸檔的表名',
  `sql_text` varchar(1024) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci NULL DEFAULT NULL COMMENT '執(zhí)行的腳本',
  `paras` varchar(1024) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci NULL DEFAULT NULL COMMENT '實際執(zhí)行參數(shù)',
  `flag` varchar(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci NULL DEFAULT NULL COMMENT '是否執(zhí)行成功:成功,失敗',
  `result_text` text CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci NULL COMMENT '執(zhí)行結果描述',
  `row_num` int NULL DEFAULT NULL COMMENT '影響行數(shù)',
  `exec_times` int NULL DEFAULT NULL COMMENT '執(zhí)行耗時ms',
  `create_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`) USING BTREE,
  INDEX `flag`(`flag` ASC) USING BTREE,
  INDEX `create_time`(`create_time` ASC) USING BTREE
) ENGINE = InnoDB AUTO_INCREMENT = 1 CHARACTER SET = utf8mb4 COLLATE = utf8mb4_0900_ai_ci COMMENT = '歸檔日志表' ROW_FORMAT = Dynamic;

# 因為我們后續(xù)將會以此條件去刪除原表數(shù)據(jù)，繼而寫入目標表(若無索引在千萬級表中想刪除部分數(shù)據(jù)那可真難哦)
ALTER TABLE `biz_order` ADD INDEX `idx_create_status`(`gmt_create`, `order_status`);

# 拿按小時歸檔舉例
LocalDate startDate = '2023-07-01'; # 舉例直觀說明，非實際Api
LocalDate endDate = '2023-07-31';
for (LocalDate tmpDate = startDate; tmpDate.isBefore(endDate;
    tmpDate = tmpDate.plusHours(1)) {
    1. 開啟事務
    2. insert into biz_order_history select * from payment where create_time >= '2023-07-01 00:00' and create_time < '2023-07-01 01:00' and order_status in (1, 2);
    3. delete from biz_order where create_time >= '2023-07-01 00:00' and create_time < '2023-07-01 01:00' and order_status in (1, 2);
    # 以上任何一個步驟異常都將進行回滾并記錄 biz_archive_log 日志
    # 若插入 biz_archive_log 日志也失敗則忽略，不影響業(yè)務
    4. insert into biz_archive_log
    5. 提交事務
}
# 具體使用什么歸檔方式取決于具體要歸檔的表，需慎重評估：粒度太大會執(zhí)行較慢，形成慢SQL大事務影響業(yè)務。粒度太小則也會造成歸檔時間過長，從服務器延遲高(埋個伏筆，下面會提到)

# 首先分析異步主從為什么會有延遲(這里使用的是異步復制)
a. 主庫執(zhí)行完一個事務，寫入binlog，我們把這個時刻記為T1
b. 主庫同步數(shù)據(jù)給從庫，從庫接收完這個binlog的時刻，記錄為T2
c. 從庫執(zhí)行完這個事務，這個時刻記錄為T3
所謂主從延遲，其實就是指同一個事務，在從庫執(zhí)行完的時間和在主庫執(zhí)行完的時間差值，即T3-T1

# 主從延遲出現(xiàn)原因
a. 機器性能差
b. 從庫的壓力大
c. 大事務
d. 網(wǎng)絡延遲
e. 從庫數(shù)量多，復制壓力大
f. 低版本只支持單線程復制，高版本是支持多線程復制