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