SyncTool 不是要替代 Debezium 或 Flink CDC，而是在「配不上一套流式基础设施」的场景里，给你一个决定性的选择
| 维度 | SyncTool | Debezium + Kafka | Canal | Flink CDC | DataX | SymmetricDS |
|---|---|---|---|---|---|---|
| 部署形态 | 单个 jar | Kafka + Connect + ZK/KRaft | Canal Server (+MQ) | Flink 集群 (JM/TM) | 客户端脚本 | 每节点部署引擎 |
| 外部依赖 | 无 | Kafka、ZooKeeper | ZooKeeper（集群） | Flink、Checkpoint 存储 | 无（但需 JSON 作业） | 数据库触发器 |
| 配置方式 | Web 界面点选 | YAML/REST + 代码消费 | 配置文件 + 客户端代码 | SQL/DataStream 代码 | JSON 作业文件 | properties + 建触发器 |
| 持续增量同步 | ✅ | ✅ 日志级 | ✅ binlog | ✅ 日志级 | ❌ 一次性 | ✅ 触发器 |
| 结构 (DDL) 同步 | ✅ 自动建表/索引/视图 | ⚠️ 仅事件 | ⚠️ 仅事件 | ⚠️ 需自定义 | ❌ 需预建表 | ⚠️ 有限 |
| 异构方言转换 | ✅ 类型/函数/引号/分页 | ❌ 需自行实现 | ❌ | ⚠️ 部分 | ⚠️ 有限 | ⚠️ 有限 |
| 国产数据库 | ✅ 达梦/金仓/GB/神通/OG | ❌ 基本不支持 | ❌ 仅 MySQL | ⚠️ 少数 | ⚠️ 需自写插件 | ⚠️ 有限 |
| 源库侵入性 | 只读查询，零侵入 | 需开 binlog/wal | 需开 binlog | 需开 binlog/wal | 只读 | 需建触发器 |
| 断点续传 | ✅ 游标持久化 | ✅ offset | ✅ | ✅ checkpoint | ❌ | ✅ |
| 可视化监控 | ✅ 看板 + 日志 | 需接 Prometheus/Grafana | 需自建 | Flink UI（偏作业） | 日志 | 有 Web 控制台 |
| 上手成本 | 分钟级 | 高 | 中高 | 高 | 中 | 中高 |
| 内网离线 | ✅ 无外网请求 | ✅ | ✅ | ✅ | ✅ | ✅ |
Debezium / Flink CDC 是优秀的流式框架，但要跑起来一条 MySQL → PostgreSQL 的链路，你需要 Kafka、Kafka Connect、协调服务，再写一个消费端把事件翻译成目标库的 DML。SyncTool 的等价操作是：java -jar synctool.jar，打开浏览器，建两个连接，建一个项目，点「启动同步」。
当同步需求的规模配不上一套流式基础设施的运维成本时，这个差距就是决定性的。
绝大多数 CDC 工具只解决「数据流」，目标表得你自己先建好。SyncTool 会读取源库元数据，按目标库方言自动创建表、索引、视图、存储过程，并在源库 DDL 变更后把差异传播过去。跨异构库迁移里，建表和类型映射的工作量往往比搬数据本身更大。
达梦、人大金仓、南大通用、神通、OpenGauss 是内置的一等选项 —— 不是「通过通用 JDBC 也许能连上」，而是各自有专门的方言实现：MERGE INTO ... FROM DUAL 的 upsert 写法、类型上限（Oracle VARCHAR2 4000）、函数名差异、标识符引号规则都已处理。Oracle/SQL Server → 国产库的替换场景是本工具的主战场。
SymmetricDS 需要在源库建触发器；Debezium / Canal / Flink CDC 需要开启 binlog / WAL 逻辑复制并申请复制权限。SyncTool 只需要一个只读账号，通过查询游标列做增量，源库结构和配置一动不动。
Navicat / DBeaver 的「数据传输」和 DataX 解决的是「把数据搬过去一次」。SyncTool 解决的是「让两边持续保持一致」：进程重启后从游标继续、停机期间的变更会被补齐、每一行写入都是幂等的。这是两个完全不同的问题。
诚实地讲清边界，比把产品吹成万能更重要。
full-compare-max-rows 的表启用。