MySQL作为DataX目标端需预建表，主键/唯一索引必须存在，字符集须为utf8mb4，JDBC URL需显式指定serverTimezone和编码参数，时间字段推荐DATETIME(3)，大表同步须合理配置splitPk、fetchSize与batchSize。
MySQL 作为 DataX 的目标端时，不会自动建表，也不会容忍主键缺失、字符集错配或时间精度丢失——这些不是配置疏漏，而是同步失败的确定性原因。
mysqlwriter 必须预建表，否则直接报 Table 'xxx' doesn't exist
DataX 的 mysqlwriter 只写数据，不执行 DDL。哪怕源是 Oracle 或 SQL Server，它也不会推导并创建 MySQL 兼容的表结构。
- 先用源库导出原始 DDL（如 Oracle 用
DBMS_METADATA.GET_DDL），再人工适配：比如NUMBER(10,2)→DECIMAL(10,2)，DATE→DATETIME - 字段名含空格、大小写混用或 MySQL 保留字（如
order、desc）必须用反引号包裹：`order` - 确认目标库/表字符集为
utf8mb4，且 MySQL 服务端character_set_server=utf8mb4已生效
writeMode: "replace" 依赖主键/唯一索引，无主键=全量插入+静默覆盖
当目标表没有主键或唯一索引时，writeMode: "replace" 实际退化为普通 INSERT；而 "update" 模式则因无匹配条件导致整批数据被丢弃，日志里还不报错。
- 务必在同步前执行：
SHOW INDEX FROM table_name WHERE Key_name = 'PRIMARY'，确认主键存在 - 若源端有业务主键（如
order_id），就在 MySQL 目标表上显式建UNIQUE KEY (order_id)，别指望应用层兜底 - 避免同步中手动删改目标表数据——DataX 不维护状态，重跑任务不会跳过已存在记录，可能引发重复或覆盖
JDBC URL 必须显式携带 utf8mb4 和 serverTimezone 参数
默认 JDBC 连接不指定参数时，中文会变成 ???，DATETIME 字段时间偏移 8 小时，毫秒级精度（如 datetime2(7)）直接被截断。
- 在
mysqlwriter的connection配置中硬编码参数："jdbcUrl": "jdbc:mysql://host:3306/db?useUnicode=true&characterEncoding=utf8mb4&serverTimezone=Asia/Shanghai" - 时间字段类型优先选
DATETIME(3)或TIMESTAMP(3)（MySQL 5.6.4+），对应 DataXcolumn类型写date，值保持字符串格式："2024-01-01 12:34:56.123" - MySQL 8.0+ 默认开启
STRICT_TRANS_TABLES，超长字符串或非法日期会中断同步，临时调整需谨慎，更推荐在源头清洗或改用writeMode: "insert"
大表同步卡死或 OOM，核心是 reader/writer 分片与 fetchSize/batchSize 匹配
单线程拉全量、JDBC 批量写入未调优、MySQL 服务端未放宽限制，三者叠加会让千万级表同步停滞甚至内存溢出。
-
mysqlreader中设置"splitPk": "id"启用分片（要求该字段有索引且分布均匀） - 调小
fetchSize（如 1000）防 reader 端 OOM，调大batchSize（如 1024）提升 writer 写入吞吐 - 同步前检查 MySQL 服务端参数：
max_allowed_packet≥ 64M，wait_timeout≥ 3600，必要时在 JDBC URL 加&connectTimeout=60000&socketTimeout=3600000
最容易被忽略的是：DataX 同步全程不校验数据一致性，也不感知源端写入。只要没停写，哪怕只差一条 UPDATE，结果就不可信——这不是工具缺陷，而是离线同步的本质约束。
