MySQL 历史数据如何归档和定期清理？NineData 配置与实施指南
【摘要】 使用 NineData 配置 MySQL 历史数据归档与定期清理的方法，覆盖归档策略、时间字段、保留天数、业务过滤、周期调度、SQL 预览、冲突处理、审批及 Optimize 空间回收注意事项。
订单、操作日志、消息记录等业务表持续增长后，历史数据会占用在线存储空间，并增加查询、备份和日常维护的成本。这些数据访问频率不高，却未必能够直接删除：业务查询、问题追溯和数据保留要求，都可能需要继续保存。
针对这类场景，NineData 提供数据归档与清理功能：按照时间字段、保留天数和过滤条件识别历史数据，将其归档到目标数据库，再清理源端已归档数据。任务支持单次执行和周期执行，并提供 SQL 预览、审批、时区配置、执行时长限制和 Optimize 策略。
本文以 MySQL 订单历史数据为例，介绍如何配置归档任务，以及上线前需要验证的关键事项。
一、先确定：仅归档、归档后清理，还是直接清理
历史数据治理首先要明确数据去向。NineData 提供三种策略：
| 策略 | 执行行为 | 适用场景 |
| 仅归档 | 将符合条件的数据复制到目标库，保留源端数据 | 首次验证归档结果，或需要保留在线副本 |
| 归档＋清理 | 先归档，再删除源库中已归档的数据 | 将历史数据迁出业务库 |
| 仅清理 | 删除符合条件的数据，不归档 | 已确认无需保留的过期数据 |
归档不能替代备份。归档用于管理历史数据的存放位置和保留范围；备份用于故障恢复。业务库和归档库仍应分别配置备份与恢复机制。
对第一次实施的生产系统，建议先执行小范围“仅归档”，确认数据范围、字段映射和查询结果，再配置正式的“归档＋清理”任务。
二、实施前提与示例场景
-
NineData 使用条件
使用数据归档与清理功能，需要：
-
已创建或加入组织；
-
组织已开通数据库 DevOps 企业版，订阅有效；
-
当前账号已切换到目标组织；
-
源表具有可作为归档依据的时间字段。
本文源端与归档目标端均采用 MySQL。NineData 功能文档列出的归档目标数据库还包括 PostgreSQL、MariaDB 和 GBase8a，本文不展开跨数据库归档。
-
示例：归档已完成的历史订单
假设业务表为：
CREATE TABLE orders ( id BIGINT NOT NULL PRIMARY KEY, customer_id BIGINT NOT NULL, status VARCHAR(32) NOT NULL, amount DECIMAL(18, 2) NOT NULL, created_at DATETIME NOT NULL, updated_at DATETIME NOT NULL, KEY idx_created_at (created_at) );
治理要求为：
-
在线库保留最近 365 天的订单；
-
只归档状态为
COMPLETED的历史订单； -
归档数据保存到独立 MySQL 归档库；
-
每天凌晨启动；
-
每轮任务最多执行 4 小时。
对应配置为：
| 配置项 | 示例值 |
| 策略 | 归档＋清理 |
| 源表 | orders |
| 时间字段 | created_at |
| 保留天数 | 365 |
| 数据过滤条件 | status = 'COMPLETED' |
| 频率 | 周期执行，每天 |
| 启动时间 | 1:00 |
| 执行时长限制 | 4 小时 |
时间条件与业务条件必须共同确定。“创建超过一年”不一定意味着订单已经结束。对于仍可能退款、补偿或更新的记录，应先确认生命周期，再决定是否迁出在线库。
三、在 NineData 中创建归档任务
第一步：配置基本信息与策略
进入：
数据库 DevOps > 数据归档与清理 > 创建归档与清理
填写任务名称、备注，选择“归档＋清理”，然后指定源数据源、源数据库和归档目标数据源、目标数据库。
建议任务名称包含业务对象和保留规则，例如：
订单归档_保留365天_每日执行
源库与归档库应提前完成连接测试和账号授权。正式实施前，还需要确认归档库容量、访问权限、备份策略及历史查询入口。
如果源库和归档库位于同一个数据库实例，将数据移到另一个库并不必然降低该实例的总存储占用。需要降低在线实例容量时，应结合独立归档实例规划，并处理后续空间回收。
第二步：设置执行周期、时区与时长
NineData 支持单次执行和周期执行。周期任务可以按周或按月配置，也可以选择每天执行。
本例设置：
-
频率：周期执行；
-
周期：每天；
-
时区：业务实际采用的时区；
-
启动时间：01:00；
-
执行时长限制：4 小时。
执行时长限制支持 1～24 小时。超过限制后，任务会自动终止本轮执行，避免任务持续跨入业务高峰。
需要注意，时长限制不是性能隔离机制，也不代表本轮一定完成全部积压数据。如果历史积压较大，应单独安排首次治理，再使用周期任务处理日常新增的过期数据。
多地域业务还应分别确认：
-
任务按哪个时区调度；
-
表中时间字段采用什么时间口径。
设置调度时区不能代替业务时间语义的核对。
第三步：选择源表和目标表
在「选择对象」页面添加源表，并指定归档目标表。
使用已有目标表时，需要保证结构兼容。字段名称不同时，通过「映射与过滤」配置对应关系。
也可以通过页面的新建表入口创建归档表，由 NineData 按源表结构创建目标表。
本例将订单统一写入固定归档表：
orders_archive
固定表便于集中查询。需要按归档批次分表时，可以使用日期变量命名，但要同时规划跨表查询、索引维护和历史表清理。
第四步：配置时间字段与保留天数
选择：
时间字段：created_at 保留天数：365
NineData 根据所选时间字段识别超过保留期限的数据，保留天数支持 1～3650 天。
时间字段不局限于
DATETIME。NineData 还支持将以下类型作为时间字段：-
INT -
BIGINT -
CHAR -
VARCHAR
数值或字符串类型需要配置解析方式：
| 存储方式 | 配置方法 |
| 日期字符串 | 指定与实际值匹配的时间格式 |
| Unix 时间戳 | 选择时间戳，并指定秒、毫秒或微秒精度 |
例如，毫秒时间戳不能按秒解析。格式或精度配置错误，会影响归档范围，必须在执行前通过样本和 SQL 预览检查。
第五步：配置业务过滤条件
进入「映射与过滤」，填写：
status = 'COMPLETED'
这样，归档范围由“超过保留期限”和“满足业务过滤条件”共同确定。
如果订单与订单明细、支付、退款等表存在关联，需要协调各表规则。仅归档主表、保留关联表，或者相反，都可能导致历史查询不完整。
创建多张表的归档配置，也不等于自动获得跨表业务一致性。关联数据的归档顺序和查询方式应在上线前验证。
四、目标数据冲突如何处理
MySQL 归档任务提供两种冲突策略：
| 策略 | 行为 | 决策重点 |
| 忽略 | 忽略造成冲突的操作，继续执行 | 目标已有记录是否可信 |
| 覆盖 | 覆盖目标数据 | 是否允许源端值更新归档记录 |
如果目标表存在相同主键，“忽略”可能保留目标旧值，“覆盖”则会改变已有归档数据。
因此，不能只为了让任务继续运行而选择忽略，也不能在没有确认数据来源时直接覆盖。首次执行前，先检查归档表是否包含测试数据或历史导入数据。
冲突策略不是数据校验。 对归档与清理组合任务，应在演练中验证冲突记录的处理结果以及源端清理结果，确认符合业务保留要求。
五、执行前必须预览 SQL
完成对象、时间和过滤配置后，单击「预览 SQL」，检查 NineData 将执行的归档与清理语句。
重点核对：
-
源库、源表和目标表；
-
时间字段与时间范围；
-
业务过滤条件；
-
字段映射；
-
目标数据冲突处理；
-
是否选错清理对象。
对于本例，需要确认任务只处理超过 365 天且状态为
COMPLETED 的订单。
SQL 预览用于验证配置是否符合预期，但不能证明性能一定满足生产要求。大表还应检查过滤字段索引、数据分布和实际执行情况。
六、需要按日期建表时，使用 bizdate
NineData 提供
bizdate 系统变量，支持自定义日期格式，并用于新建归档表名或条件表达式。例如，设置格式：
yyyyMMdd
目标新表名称配置为：
orders_archive_${bizdate}
执行日期为 2026 年 10 月 21 日时，对应表名为：
orders_archive_20261021
这里的日期表示任务使用的系统日期，不自动等同于订单所属月份。按执行日期创建归档表，与按订单业务日期分表，是两种不同的设计。
如果历史数据需要统一检索，固定归档表通常更容易管理；如果需要按批次隔离，应同步设计查询和保留策略。
七、通过审批后执行
NineData 归档任务可以接入审批流程。任务创建后，按配置进入预检查、提交审批和执行环节，由审批人员审核归档范围及操作内容。
建议审批时重点检查：
-
为什么需要归档或清理；
-
数据保留期限是否合理；
-
SQL 范围是否正确；
-
目标库是否具备保存条件；
-
是否完成演练和备份；
-
是否安排业务低峰窗口。
审批需要预先配置。 未配置审批流程的数据源不会自动强制要求人工审批。生产归档应先确认流程配置，再提交任务。
审批通过后，由执行人选择立即执行；一次性任务也支持定时执行。周期任务按照配置的周期和启动时间运行。
八、数据清理后，为什么磁盘空间没有明显下降
MySQL 删除记录后，释放的空间可能先留在表文件内部供后续写入复用，并不立即返还操作系统。
因此，要区分：
-
数据清理：删除不再需要的记录；
-
空间回收：整理存储结构，回收可释放的表空间。
NineData 在包含清理操作的任务中提供 Optimize 策略，可以配置执行若干次清理后，再执行一次 Optimize。
但 Optimize 不能按“无风险释放空间”处理。实际效果和执行代价取决于 MySQL 存储引擎、表空间配置、表大小及数据库版本。
生产启用前建议验证：
-
是否需要额外临时空间；
-
执行耗时；
-
对读写和锁的影响；
-
对复制延迟的影响；
-
是否真正降低了目标磁盘占用。
不要将“每天清理”直接等同于“每天执行 Optimize”。数据清理频率和空间整理频率应分别评估。
九、上线检查清单
| 检查项 | 验收内容 |
| 产品条件 | 组织、数据库 DevOps 企业版及订阅状态满足要求 |
| 数据范围 | 时间字段、保留天数、业务过滤条件正确 |
| 数据关联 | 主表与明细等关联数据已协调处理 |
| 目标结构 | 字段、类型和映射经过验证 |
| 冲突策略 | 忽略或覆盖的业务影响明确 |
| SQL 预览 | 已检查实际归档与清理语句 |
| 调度 | 时区、周期和启动时间正确 |
| 时长限制 | 执行窗口经过演练 |
| 审批 | 生产数据源已配置所需流程 |
| 数据验证 | 归档数据和源端清理结果核对通过 |
| 空间回收 | Optimize 的资源影响与回收效果已验证 |
| 恢复准备 | 业务库及归档库备份、恢复路径明确 |
NineData 将归档范围、周期调度、SQL 预览、审批和清理策略集中在控制台中管理，减少重复维护脚本和人工执行的工作。要让周期任务长期稳定运行，还需要持续检查数据增长、归档结果、执行窗口和目标容量，使历史数据治理成为可验证的日常运维流程。
【声明】本内容来自华为云开发者社区博主，不代表华为云及华为云开发者社区的观点和立场。转载时必须标注文章的来源（华为云社区）、文章链接、文章作者等基本信息，否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容，举报邮箱：
cloudbbs@huaweicloud.com
- 点赞
- 收藏
- 关注作者
评论（0）