用WHERE+时间戳字段做增量判断最常用，需建有效索引、用>而非>=防重复、统一时区、逻辑删除或CDC捕获删除、主表时间字段过滤、游标分页替代OFFSET、复合索引支持排序、预留缓冲窗口防时钟漂移。
用
+ 时间戳字段做增量判断最常用
绝大多数业务表都有
或
字段，这是实现增量同步最直接的依据。关键不是“有没有”，而是“索引是否有效”和“边界是否严谨”。
必须给时间字段建索引，否则每次查都全表扫描，增量变慢量
同步时要用
，不能用
，否则重复拉取上一批最后一条（尤其高并发更新场景）
注意数据库时区：MySQL 默认用系统时区，PostgreSQL 可能默认
，跨服务同步前先对齐时钟或统一转为 UTC 存储
处理删除操作必须靠逻辑删除或变更日志
纯靠
拉不到已删数据，所以物理删除无法被下游感知。常见解法只有两个，没有中间路线：
强制业务改用逻辑删除：加
字段 +
，同步 SQL 改为
启用数据库原生 CDC：MySQL 开
（格式必须为
），PostgreSQL 开
，SQL Server 开
——这些能捕获 INSERT/UPDATE/DELETE 全事件
避免用触发器模拟日志：维护成本高、易丢事件、影响主库性能
多表同步时，增量字段必须来自主表且可索引
比如同步订单+订单项，想按订单更新时间增量拉，就不能写
——这会漏掉“订单更新但子项没动”的情况，且
索引对主表无加速作用。
正确做法是只用主表（
）的
过滤，再关联子表；如需子表变更也触发同步，得单独建子表的增量任务
如果必须单次拉取完整订单（含最新子项），且子项有独立更新逻辑，建议在订单表加
冗余字段，由应用层或触发器维护
不要依赖
聚合后过滤：GROUP BY 会让索引失效，
大数据
量下变成慢查询
避免
分页导致的漏数据或重复
用
做分批同步，在并发写入场景下极易漏行或重复——因为 OFFSET 是基于当前快照计数，而新数据插入会挤占位置。
一律改用游标分页：
，每次用上一批最后一条的
当下一批起点
复合游标字段必须有联合索引，例如
，否则排序仍走 filesort
如果表没主键或主键不连续（比如 UUID），优先用自增
或数据库序列值做第二排序字段，别依赖
单独排序（同一秒可能多条）
实际中最容易被忽略的是时钟漂移和事务可见性：上游事务提交时间和 binlog 写入时间有微小延迟，下游如果严格按时间戳拉，可能某条刚提交的记录被跳过。这时候得预留几秒缓冲窗口，或者用位点（binlog position / LSN）代替时间戳做精确锚点。
WHEREupdated_atcreate_timeWHERE updated_at > '2024-06-01 00:00:00'>=timestamp without time zoneupdated_atis_deleteddeleted_atWHERE updated_at > ? OR deleted_at > ?binlogROWlogical replicationChange Data CaptureJOINSELECT * FROM orders o JOIN order_items i ON o.id = i.order_id WHERE i.updated_at > ?i.updated_atordersupdated_atlatest_item_updated_atMAX(i.updated_at)OFFSETLIMIT 1000 OFFSET 10000WHERE updated_at > '2024-06-01 10:00:00' ORDER BY updated_at, id LIMIT 1000(updated_at, id)INDEX idx_updated_id (updated_at, id)idupdated_at