Waterdrop同步MySQL到ClickHouse需手动对齐类型、调优写入参数并确保增量条件可靠：TINYINT→Int8/UInt8，DATETIME(6)需截断微秒，DECIMAL须显式声明；遇Code:210错误应调大ClickHouse HTTP参数、降低batchSize、禁用压缩；增量依赖单调字段如id或update_time。
Waterdrop 是一个基于 Spark 的轻量级数据同步工具，适合从 MySQL 批量导出到 ClickHouse 做 OLAP 分析，但默认配置下容易因类型映射、写入策略或并发控制不当导致任务失败或数据不一致。
MySQL 到 ClickHouse 的字段类型怎么对齐？
ClickHouse 不支持 MySQL 的 TINYINT、ENUM、JSON、DATETIME(6) 等类型，Waterdrop 默认不会自动转换，需手动映射：
-
TINYINT→ 改为Int8或UInt8（注意符号位） -
DATETIME→ 对应DateTime，但若含微秒（如DATETIME(6)），需在 SQL 查询中用date_trunc('second', col)截断，否则报Cannot parse datetime -
TEXT/VARCHAR→ 统一映射为String；大文本慎用FixedString -
DECIMAL(10,2)→ 必须显式指定为Decimal(10,2)，否则 Waterdrop 可能转成Float64造成精度丢失
Waterdrop 写入 ClickHouse 报 Code: 210. DB::NetException 怎么处理？
这是最常见的连接或写入超时错误，本质是 ClickHouse 的 HTTP 接口在高并发写入时拒绝新连接，或批量大小超出服务端缓冲限制：
- 在
clickhouse.conf中调大max_http_get_redirects和max_http_buffer_size（至少 16MB） - Waterdrop 配置里降低
batchSize（建议 ≤ 10000），并启用retry：{"retry": 3, "retryInterval": 5000} - 禁用
enableHttpCompression（Waterdrop v1.5+ 默认开启，但 ClickHouse 某些版本对压缩响应解析不稳定） - 确保 ClickHouse 表引擎为
ReplacingMergeTree或CollapsingMergeTree，避免用Memory引擎接收批量写入
增量同步时怎么避免重复写入？
Waterdrop 本身不提供 CDC 能力，所谓“增量”依赖用户自己构造条件查询，常见误区是只靠时间字段过滤：
- MySQL 端必须有单调递增的字段（如自增
id或严格递增的update_time），并在 Waterdrop 的sql参数中写死范围，例如：SELECT * FROM orders WHERE id > ${last_max_id} AND id <= ${current_max_id} - 不能依赖
NOW() - INTERVAL 1 HOUR这类动态表达式——Waterdrop 的 SQL 是静态解析的，不支持运行时计算 - 每次任务完成后，必须把本次写入的最大
id或update_time记录到外部存储（如本地文件或 MySQL 配置表），否则下次无法续跑 - ClickHouse 端建议加
WHERE _partition_id = '202409'分区写入，便于后续按分区清理重试数据
真正难的不是启动任务，而是确认每列数据在两个系统间语义一致：比如 MySQL 的 NULL 在 ClickHouse 里是否允许、TIMESTAMP 是否带时区、字符串末尾空格是否保留。这些细节不会报错，但会让分析结果偏移。上线前务必抽样比对原始值和 ClickHouse 中的 hex() 结果。
