增量同步必须有稳定锚点字段（如自增id或带索引的update_time），否则只能退全量；需确保binlog/归档日志开启、调度注入动态时间参数、目标端按分区写入、网络权限连通、删除操作专项验证，并严格校验数据一致性。
增量同步必须有“锚点字段”，否则根本跑不起来
没有可用于识别新增数据的字段，增量同步就只是空谈。不是所有表都天然带 gmt_modified 或 create_time，更别提删除操作——时间戳策略压根捕获不到删行。一旦源表缺少稳定、单调递增、非空且索引覆盖的字段（比如自增 id 或带索引的 update_time），你就只能退回到全量同步，或者硬加触发器/日志解析，成本陡增。
- 优先检查源表是否存在已建索引的
id或update_time字段；没索引的字段即使存在也极慢，别信“能用就行” - 若字段值存在空值、时区混乱、或被业务逻辑重置（如定时脚本把
update_time改成当前时间），同步会漏数据或重复拉取 - MySQL 5.7+ 的
binlog_format=ROW是日志法前提；Oracle 需开启ARCHIVELOG+ 补充日志；没开等于白配
DataX 做增量必须手动切分任务，不能只靠一个 JSON
DataX 本身不内置增量状态管理，job.json 里写的 where 条件（比如 "where": "update_time > '2026-03-10 00:00:00'"）只是静态快照。真正跑起来要靠外部调度（比如 Airflow、DataWorks）每次传入新时间窗口，并确保上一次成功写入后才更新参数——否则断点续传失效，重跑就重复。
- 别把
where写死在 JSON 里；必须由调度系统注入变量，例如用${bdp.system.bizdate}或${dt} - Writer 端（如 Hive）要配合分区字段，比如按天写入
ds='20260312'，否则增量数据混在历史分区里，后续查不出“净新增” - Reader 并发数设太高（如
channel> 8）可能触发源库连接池打满，尤其 Oracle/SQL Server；建议从 2 开始压测，观察DBA_SHOW_PROCESSLIST或慢日志
云上大数据增量同步，别只盯工具，先看网络和权限链路
在阿里云、AWS 这类环境里，DataX 或 FDL 跑得慢，90% 不是配置问题，而是跨 VPC、跨地域、跨账号时权限和路由没对齐。比如 DataX 从 RDS MySQL 同步到 EMR Hive，中间至少经过：RDS 白名单 → ECS 安全组 → EMR 集群 Kerberos 认证 → HDFS ACL → Hive Metastore 权限。漏一环，不是连不上，就是写失败但报错模糊。
- 用
telnet rds-endpoint 3306和hadoop fs -ls hdfs://emr-cluster/分别验证连通性，别只看 DataX 日志里的 “Connection refused” 就去调 JDBC 参数 - 云数据库的“只读实例”默认不开启 binlog（如阿里云 RDS MySQL 只读节点），日志同步直接失败；必须主实例开启，且同步任务指向主节点
- 目标端写入慢？先查
hdfs dfsadmin -report看 DataNode 磁盘使用率，超 85% 会导致写入阻塞，比调batchSize有用得多
校验不是可选项，而是上线前最后一道闸门
增量同步最容易骗过人的，就是“任务跑成功了，日志没报错”。但字段类型隐式转换（比如源端 VARCHAR(255) 写进目标端 STRING 却截断）、时区偏移（UTC 存的 update_time 被当成本地时间解析）、甚至 Kafka 消费位点提交失败导致重推，都会让数据“看起来对”，实际差几万条。
- 用 SQL 对比关键聚合：源端
SELECT COUNT(*), MIN(id), MAX(id) FROM t WHERE update_time > '2026-03-12'，目标端同条件查，三值必须完全一致 - 抽样校验至少 0.1% 主键：把源端增量 ID 导出为文件，用
hadoop fs -cat读目标端对应分区，diff或comm比对，别只信 count - 删除操作必须单独验证——加个临时表记录 delete_log，或者用 CDC 工具带 delete 标记，否则永远不知道有没有漏掉删行
增量同步的复杂性不在代码行数，而在状态边界是否清晰。时间戳字段有没有被业务改写、binlog 是否实时落盘、调度参数有没有被缓存、校验脚本是不是只跑了一次……这些细节没卡死，跑得越快，翻车越晚。
