归档目标是分层管理历史数据，即保障在线业务性能、满足合规留存要求、降低存储成本，且归档后须可查可追溯；归档范围应按时间、状态、业务规则三重过滤。
归档目标要明确：不是“删数据”，而是“分层管理”
历史数据归档不是简单地把旧数据扔进另一个库就完事。核心目标是：保障在线业务性能（减少主表体积、加快查询响应）、满足合规留存要求（如金融/医疗行业需保留5–10年原始记录）、降低存储成本（热数据用高性能SSD，冷数据可转对象存储或压缩归档表）。关键前提是——归档后仍需可查、可追溯、可还原，不能因归档导致审计失败或业务补数困难。
归档范围怎么划：按时间+状态+业务规则三重过滤
单靠“早于某日期”一刀切容易出问题。建议组合判断：
- 时间维度：例如订单表中，status = 'completed' 且 updated_time
- 业务状态锁死：确保归档的数据已无更新可能（如发票已开票、退款已终态、合同已履约完毕）
- 关联完整性校验：归档主表前，先确认其外键关联的明细、日志、附件等是否同步归档或已持久化备份
归档实施要可控：分批迁移 + 原子校验 + 可逆回滚
千万级表直接 DELETE + INSERT 极易锁表、拖垮线上服务。推荐渐进式操作：
- 用 LIMIT + ORDER BY id 分批次（如每次5万行），配合 sleep(0.1) 控制节奏
- 每批迁移后，执行 COUNT + SUM(id) 或 CRC32 校验，确认源表删、目标表增数量一致
- 归档脚本内嵌“反向恢复语句”（如INSERT INTO source SELECT * FROM archive WHERE batch_id = ?），故障时可快速回填
- 归档完成后，对原表执行 OPTIMIZE TABLE（InnoDB）或 VACUUM（PostgreSQL）释放碎片空间
归档后怎么用：统一访问层 + 元数据标记 + 冷热路由
用户不关心数据在哪，只关心“能不能查”。建议：
- 在应用DAO层或中间件（如ShardingSphere、MyCat）增加路由逻辑：自动识别查询条件中的时间范围，命中归档表时转向归档库或归档分区
- 所有归档表加统一字段：archive_date（归档执行时间）、archive_source（来源库表名）、archive_batch（批次号），便于追踪和清理
- 对高频访问的历史报表类需求，可在归档库中建立轻量聚合视图或物化摘要表（如按月汇总订单金额），避免反复扫描全量冷数据
