数据库同步全量、增量字段、CDC 怎么选：上线前别只看延迟

做数据库迁移同步时，全量、增量字段和 CDC 不是谁更高级的问题。本文用决策树、检查清单和校验 SQL 拆解数据量、延迟、删除事件和目标表策略，帮助你选对同步模式。

做数据库同步时，很多人一上来就问：“能不能实时？”

这个问题没错，但只问实时会漏掉更关键的约束：目标库是不是空的，源表有没有可靠的增量字段，删除数据要不要同步，源库日志和权限有没有准备好，任务失败后怎么确认目标端没少数据。

先给结论：

不要只看“实时”两个字

我见过不少同步任务，方案评审时大家都倾向 CDC，因为听起来更高级。可真正上线时，问题经常出在很朴素的地方。

比如目标库已经有历史数据，初始快照要不要清空目标表？源表的 update_time 有些老数据会被回填，增量字段还能不能用？任务进度显示完成了，但写入端有错误数据，业务表实际少了几行，谁来兜底？

所以同步模式不是按功能强弱排序，而是按业务约束匹配。

三种模式怎么理解

全量同步：适合建立数据基线

全量同步最容易理解：从源表读取完整数据，写入目标表。它适合初始化目标库、历史补数、低频迁移和一次性任务。

全量的风险也很直接：

DataMover 的普通任务支持全量同步。全量模式下可以配置批大小，默认可以先用 5000 跑通；大表再考虑分片字段。别一上来就把批大小调很大，Worker 内存、目标端写入能力和网络都会影响效果。

增量字段同步：适合“能按字段追”的表

增量字段同步的核心是找一个能代表新数据或变更顺序的字段。常见选择是自增 ID、update_time、入库时间、业务流水号。

它的好处是配置轻，不一定需要打开数据库日志。问题是，它对字段质量要求很高。

适合用增量字段的表，通常满足这些条件：

这里要说一句实话：增量字段同步不是 CDC 的平替。它更像“按字段继续往后拉”。如果业务会物理删除数据，或者历史记录被回填到旧时间段，单靠增量字段就容易漏。

DataMover 会记录增量字段同步进度，异常后可以从记录位置继续跑。生产场景里不要只依赖这个进度记录，执行日志、错误数据和目标端 SQL 校验都要一起看。

CDC：适合持续捕获数据库变更

CDC 更适合长期同步。它通过读取数据库变更日志捕获 INSERT、UPDATE、DELETE，适合实时数仓、业务库到报表库、生产到备库、应用解耦等场景。

但 CDC 不是“点一下就万事大吉”。上线前至少要看这些条件：

DataMover 的实时任务基于 Debezium，当前前端实时源端可选择 MySQL、PostgreSQL、Oracle、SQL Server、达梦。免费版也支持 CDC，但仍然受免费版的数据源、任务数和节点规格限制。

选择时可以按这张表判断

一个比较稳的落地顺序是：先用全量建立基线，再根据后续变化选择增量字段或 CDC。很多项目不是只选一种模式，而是“全量初始化 + 增量持续同步”。

上线前检查清单

这部分建议直接放进上线单里。少一项，后面排查就会很痛苦。

在 DataMover 里怎么落地

如果用 DataMover 做这类任务，操作路径可以按下面走：

1. 新建源端和目标端数据源，先测试连接。
2. 新建普通任务或实时任务。普通任务用于全量、增量字段；实时任务用于 CDC。
3. 选择源表和目标表，确认是否自动建表。
4. 进入字段映射，检查类型、默认值、主键、自增或序列差异。
5. 普通任务进入同步策略配置：选择全量或增量字段，设置批大小、调度方式，必要时配置分片。
6. 实时任务确认是否执行快照。目标表已有数据时，不要跳过这一步。
7. 启动任务后看执行记录、输入输出统计、失败数据和日志。
8. 用 SQL 校验目标端，不要只看页面进度。

DataMover 的价值在这里不是把所有风险“自动消失”，而是把数据源、任务、映射、调度和监控集中到 Web 界面里。你少写很多一次性脚本，但该做的上线检查仍然不能省。

可复制的校验 SQL

行数一致只是第一层。真正上线时，至少再补时间范围、关键字段聚合和抽样。

-- 行数校验
SELECT COUNT(*) FROM source_table;
SELECT COUNT(*) FROM target_table;

-- 时间范围校验
SELECT MIN(update_time), MAX(update_time) FROM source_table;
SELECT MIN(update_time), MAX(update_time) FROM target_table;

-- 关键字段聚合校验
SELECT status, COUNT(*) FROM source_table GROUP BY status ORDER BY status;
SELECT status, COUNT(*) FROM target_table GROUP BY status ORDER BY status;

-- 抽样校验
SELECT * FROM source_table WHERE id IN (1, 100, 1000);
SELECT * FROM target_table WHERE id IN (1, 100, 1000);

如果是金额类、库存类、订单状态类表，再加一组业务聚合：

-- 金额类字段聚合校验
SELECT status, COUNT(*) AS cnt, SUM(amount) AS total_amount
FROM source_table
GROUP BY status
ORDER BY status;

SELECT status, COUNT(*) AS cnt, SUM(amount) AS total_amount
FROM target_table
GROUP BY status
ORDER BY status;

常见误区

误区一：有 update_time 就一定能做增量

不一定。要看更新旧数据时 update_time 会不会变，历史数据会不会被补录到过去的时间点，应用有没有绕过统一更新时间逻辑。

如果这些都不稳定，增量字段同步就只能覆盖一部分场景。

误区二：CDC 一定比增量字段好

CDC 能捕获更多事件，但它需要日志、权限、位点和 DDL 流程。对一个每天同步一次的报表表来说，CDC 可能是过度设计。

工具选型不是越复杂越好。够用、可解释、好排查，才适合长期跑。

误区三：任务完成等于数据一致

任务完成代表流程跑完，不代表业务数据已经完全一致。尤其是写入端存在失败记录、目标端约束拦截、字段截断、时间偏移时，页面进度很容易给人错觉。

所以要看错误数据，也要做 SQL 校验。

推荐阅读和下一步

如果你准备实际试一遍，可以从 DataMover 下载页 获取安装包，部署步骤看 DataMover 文档。

相关内容也可以继续看：

• DataMover Docker 部署
• DataMover 支持的数据源
• SQL Server 到 MySQL 数据迁移同步
• MySQL 到达梦数据库迁移同步

FAQ

全量同步、增量字段同步和 CDC 怎么选？

首次初始化、历史补数或低频覆盖，优先选全量。源表有可靠自增 ID 或更新时间字段、能接受分钟级延迟，可以选增量字段。需要捕获 INSERT、UPDATE、DELETE，且希望秒级延迟时，优先看 CDC。

增量字段同步能替代 CDC 吗？

不能完全替代。增量字段同步适合追加数据或按更新时间拉取的数据。物理删除、未更新时间的旧数据变更、日志级变更捕获，还是更适合 CDC。

DataMover 免费版支持 CDC 吗？

支持。免费版支持 CDC，但要同时注意免费版的数据源范围、任务数和节点数限制。实际配置前还要确认源库日志和账号权限。

同步任务完成后怎么确认目标库数据完整？

不要只看进度条。建议同时检查执行记录、错误数据、任务日志，并用行数、时间范围、关键字段聚合和主键抽样 SQL 做目标端校验。

目标表已经有数据，还能执行快照吗？

可以，但要非常谨慎。快照或清空策略可能影响已有数据。生产环境建议先备份目标表，明确是覆盖、追加、写新表，还是只从当前位点开始同步。