时间戳和版本号增量同步需确保字段可靠更新、建立索引、统一时区、避免边界重复；版本号需单调递增并配合软删；delete+INSERT需额外处理；CDC或变更日志更可靠；checkpoint须与写入原子性一致。
用 WHERE updated_at > ? 做时间戳增量同步
时间戳方案最常见，但必须确保 updated_at 在业务写入时被可靠更新（比如 ORM 的自动更新、数据库触发器或应用层显式赋值）。如果字段允许为 NULL 或存在批量导入未设值的情况，会导致漏数据。
实操建议：
- 首次全量同步后，记录最大
updated_at值（如'2024-06-15 14:22:33'），后续每次查询都用这个值作为下限 - 使用
WHERE updated_at > ?而非>=，避免重复拉取边界记录（尤其在高并发写入、毫秒级精度不足时） - 注意数据库时区：确保应用、数据库、同步任务三者时区一致，否则可能跳过或重复；推荐统一用 UTC 存储和比较
updated_at - 如果表无索引，
updated_at字段必须建 B-tree 索引，否则全表扫描会拖垮性能
用 WHERE version > ? 做整数版本号增量同步
版本号方案更精确，适合强一致性要求场景，但依赖业务逻辑保证每次更新必增 version（如 UPDATE t SET data=?, version=version+1 WHERE id=? AND version=? 的乐观锁模式）。
实操建议：
- 首次同步后记下最大
version（如12847），下次请求WHERE version > 12847 - 版本号必须是单调递增的整数，不能用 UUID 或哈希值替代
- 删除操作难表达：通常需额外字段（如
is_deleted）或软删机制配合，否则纯 version 无法捕获 DELETE - 注意整数溢出风险——若用
SMALLINT，上限仅 32767，高频更新表应选BIGINT
处理“先删后插”导致的增量丢失问题
有些业务为简化逻辑，用 DELETE + INSERT 替代 UPDATE，这会使 updated_at 和 version 都重置，旧主键记录的变更无法被下游感知。
应对方式：
- 强制要求业务改用 UPDATE，或在 DELETE 前先发一条标记为 “deleted” 的变更事件
- 引入单独的变更日志表（如
change_log），所有 DML 操作由触发器或应用层写入该表，下游只读这个表 - 对关键表启用数据库原生 CDC（如 postgresql 的 logical replication、mysql 的 binlog），绕过应用层逻辑缺陷
同步中断后如何安全续传
网络抖动或任务崩溃后，不能简单重试上一次的查询条件，否则可能跳过部分数据（例如上次查到 updated_at = '2024-06-15 14:22:33'，但该时刻有 3 条记录，只成功写入前 2 条就断了）。
可靠做法：
- 下游写入成功后，再更新本地 checkpoint（如把最新成功处理的
updated_at或version写入配置表或文件） - checkpoint 必须与数据写入在同一事务中提交（如支持 XA 的场景），或至少用原子性写入（如先写数据，再用
REPLACE INTO更新 checkpoint 表） - 避免用“最后一条记录的时间戳”作为 checkpoint——它不等于“所有 ≤ 该时间的数据都已落地”，而应是“所有
时间戳和版本号都不是银弹。真正棘手的是业务写法不规范、删除语义缺失、以及 checkpoint 更新时机错位——这些地方一松动，增量就不可靠。