DataX比mysqldump更适合归档迁移，因其支持多线程、断点续传、QPS可控、避免长事务，且天然适配只读、范围筛选及异构目标；而mysqldump为单线程、全表锁、无并发控制，易拖垮主库。

为什么DataX比mysqldump更适合归档迁移

因为mysqldump是单线程、全表锁（或至少读锁）、不支持断点续传，10亿级历史数据归档时容易拖垮主库、超时失败、无法控制并发节奏。而DataX基于JVM多线程拉取+内存缓冲+失败重试机制，能稳定控制QPS、避免长事务、天然适配归档场景的“只读+范围筛选+目标异构”需求。

配置DataX任务时必须改掉的默认项

开箱即用的mysqlreader和mysqlwriter模板在归档场景下极易出错，以下参数不手动覆盖就会踩坑：

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

• "splitPk": "id" —— 必须指定主键或有索引的整型字段，否则无法切分；时间字段如create_time不能直接用作splitPk，需先建索引+转成整型（如UNIX_TIMESTAMP(create_time)）
• "where": "create_time —— 归档条件必须写在<code>where里，不能靠SQL拼接；注意时区一致性，建议统一用UTC或显式CONVERT_TZ
• "batchSize": 10000 —— 默认512太小，归档场景可设为5000–20000，但需配合目标库innodb_log_file_size调整，避免写入卡住
• "writeMode": "insert" —— 若目标表已存在且需去重，改用"replace"；但归档表一般空表，用insert更安全

如何避免归档过程中主库被查崩

即使加了where条件，DataX默认仍会执行SELECT COUNT(*)估算总行数——这对大表就是一次全索引扫描。必须禁用：

• 在job.content[0].reader.parameter中显式添加"querySql": ["SELECT id, create_time, ... FROM orders WHERE create_time ，绕过自动COUNT
• 给create_time字段建联合索引：INDEX idx_archive (create_time, id)，确保WHERE+ORDER BY+分片都能走索引
• 用--jvm="-Xms2g -Xmx4g"启动参数限制内存，防止OOM后触发频繁GC拖慢整个JVM进程

导出到文件而非数据库时的关键路径设置

归档最终要落盘长期保存，DataX支持直出CSV/JSON，但路径和编码稍不注意就乱码或权限报错：

• "path": "/data/archive/orders_2024_q1.csv" —— 路径必须由DataX进程用户可写，且父目录存在；推荐用绝对路径，避免相对路径在crontab中失效
• "fileName": "orders_2024_q1" —— 不带扩展名，format字段决定后缀，如"format": "csv"
• "column": [{"name":"create_time","type":"date"},{"name":"amount","type":"double"}] —— 显式声明字段类型，避免datetime被转成毫秒时间戳；中文字段需确认源库character_set_client和collation_connection为utf8mb4
• 导出完成后务必校验：head -n 2 /data/archive/orders_2024_q1.csv | iconv -f utf8mb4 -t utf8 看是否乱码

实际归档不是“跑通就行”，而是每一步都要预判对主库的影响边界：比如分片数量翻倍不一定提速，可能触发更多IO争抢；CSV导出看似简单，但没设dateFormat会导致2024-01-01 12:34:56被截断成2024-01-01。这些细节不提前验证，上线后就是半夜告警。