适用场景

生产库越来越慢，往往不是硬件不行，而是三年前的数据还在里面。归档的价值是双向的：生产库变快，历史数据还能查。关键是归档要合规、可检索、可验证。

配置步骤（归档策略与执行）

-- 1) 先量化：找出大表与冷数据占比
SELECT table_name, table_rows,
       ROUND(data_length/1024/1024) AS data_mb,
       ROUND(index_length/1024/1024) AS idx_mb
FROM information_schema.tables
WHERE table_schema = DATABASE()
ORDER BY data_length DESC LIMIT 15;

-- 2) 冷数据识别（示例：2 年前且已结案）
SELECT COUNT(*) FROM biz_order WHERE created_at < '2024-09-01' AND status = 'closed';

-- 3) 归档（分批 + 限速思路）
-- a. 建历史库历史表（结构一致，索引精简）
-- b. INSERT INTO hist.biz_order SELECT ... WHERE ... LIMIT 1000; 循环
-- c. 校验行数与汇总
-- d. 确认无误后删除生产库数据（分批，避免长事务）

关键参数与建议

  • 划分标准：按时间（超过 N 个月）、按状态（已结案/已结束）双维度
  • 保留期：按法规与业务要求定（财务/交易类通常 5-10 年），到期清理要审批
  • 归档形式：历史库（可查询）+ 归档文件（对象存储/磁带，必要时可恢复）
  • 检索：业务方要能查历史数据，提供只读查询入口，避免「归档即失联」
  • 一致性：归档前后行数与汇总值必须校验，抽样比对关键字段
  • 删除策略：确认合规与财务要求后再删，删除要有审批与备份
  • 性能：归档任务限速，避开业务高峰，注意归档期间的索引与锁
  • 记录：归档批次、数据范围、负责人、校验结果全部留档

容易踩的坑

  • 一次性 DELETE 几千万行，产生巨大事务与主从延迟
  • 归档后不校验，数据少了没人发现
  • 历史库没有查询入口，业务方查到不到只能找开发
  • 索引照抄生产，历史库体积没降多少
  • 删除没审批，遇到审计时拿不出依据
  • 归档脚本没有幂等设计，重复执行造成重复数据

验证与巡检

-- 归档前后核对
SELECT COUNT(*) FROM biz_order;
SELECT COUNT(*) FROM hist.biz_order;
SELECT SUM(amount) FROM biz_order WHERE created_at < '2024-09-01';
SELECT SUM(amount) FROM hist.biz_order WHERE created_at < '2024-09-01';

-- 生产库瘦身效果
SELECT ROUND(data_length/1024/1024) FROM information_schema.tables
WHERE table_name = 'biz_order';
  • 巡检：行数与汇总一致、查询入口可用、归档批次有记录、生产库体积与查询耗时下降

小结

归档验收：生产库瘦身可量化（表大小/查询耗时下降），历史数据能按业务需求查回，行数与汇总校验一致，合规保留期有依据。

> 说明：文中命令为通用写法，不同型号/版本可能略有差异，落地前请对照设备实际版本的官方文档；带外管理与安全设备变更建议先在测试设备验证。