如何采用MySQL的数据泵技术实现高效的数据归档？

mysqlpump 不适合直接做归档操作，本质是逻辑备份工具，仅支持全量快照导出，不具备按时间筛选、边归档边删、事务级一致性控制等归档所需能力，仅适用于停写后的冷备迁移场景。

mysqlpump 不适合直接做归档操作

直接用 mysqlpump 做“归档”是个常见误解。它本质是逻辑备份工具，不是增量迁移或在线归档工具。它导出的是快照（SELECT * FROM table 的结果），无法按时间条件筛选、不能边归档边删、也不支持事务级一致性控制。如果你试图用 mysqlpump 导出旧数据再手动导入归档库，会遇到三个硬伤：源表锁表风险高、时间范围难精确控制、删除动作必须额外写脚本且易丢数据。

真正能配合 mysqlpump 的归档场景只有冷备迁移

当归档目标是“彻底下线某历史库”，且业务允许停写时，mysqlpump 才有用武之地。比如把 2022 年前的订单库整体迁移到归档实例：

• 先停写源库，确保无新数据写入
• 用 mysqlpump -u root -p --databases old_orders_db --no-create-db --skip-triggers > archive_2022.sql 导出（加 --no-create-db 避免建库冲突）
• 目标库提前建好同名库，再用 mysql -u root -p old_orders_db 导入
• 验证 COUNT(*) 和主键最大值是否一致，确认无截断

注意：mysqlpump 默认不导出 CREATE DATABASE 语句，但会导出 USE db_name，所以目标库必须已存在且字符集匹配；若原库有大量 BLOB 字段，建议加 --compress-output=ZLIB 减小传输体积。

想在线归档？得换工具或方案

生产环境要边查边归档、按 create_time 切片、控制每批 1000 行，mysqlpump 完全做不到。可行路径只有三条：

• 用 pt-archiver：支持 --where "create_time + <code>--limit 1000 + --bulk-insert，自动分批、带错误重试、可指定目标库表
• 用分区表 + ALTER TABLE ... DROP PARTITION：前提是建表时就按时间分区，归档就是 detach 整个分区，毫秒级完成
• 手写存储过程循环：用 INSERT INTO archive_db.t SELECT ... WHERE ... AND id BETWEEN ? AND ? + DELETE 成对执行，但必须加 START TRANSACTION 包裹，且需监控 innodb_row_lock_waits

真正容易被忽略的是归档后的查询路径——归档表如果没建 INDEX(create_time)，后续查某年订单反而比原表还慢；而 mysqlpump 导出的 SQL 文件里默认不含索引语句，导入后得手动补。