许多数据库管理员在进行数据归档时，会首先想到 mysqlpump，但必须明确指出：它本质上属于逻辑备份工具，并非增量迁移或在线归档的解决方案。导出的仅是全量快照（即 SELECT * FROM table 的结果），既无法按时间条件筛选，也不能边归档边删除，更不支持事务级一致性控制。如果试图用 mysqlpump 导出旧数据再手动导入归档库，将面临三大痛点：源表锁表风险高、时间范围难以精确控制、删除操作需额外编写脚本且极易丢失数据。
mysqlpump 不适合直接用于数据归档操作
直接使用 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 < archive_2022.sql导入 - 验证
COUNT(*)和主键最大值是否一致，确保数据无截断
注意事项：mysqlpump 默认不导出 CREATE DATABASE 语句，但会包含 USE db_name，因此目标库必须已存在且字符集匹配；若原库含有大量 BLOB 字段，建议加上 --compress-output=ZLIB 以减小传输体积。
在线归档需求？请更换工具或方案
生产环境中若需要边查询边归档、按 create_time 分批处理、控制每批 1000 行，mysqlpump 完全无法胜任。可行的替代方案主要有三种：
- 用
pt-archiver：支持--where "create_time +--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 文件默认不含索引语句，导入后必须手动补充。
