17370845950

用WHERE+时间戳字段做增量判断最常用，需建有效索引、用>而非>=防重复、统一时区、逻辑删除或CDC捕获删除、主表时间字段过滤、游标分页替代OFFSET、复合索引支持排序、预留缓冲窗口防时钟漂移。

用 WHERE + 时间戳字段做增量判断最常用

绝大多数业务表都有 updated_at 或 create_time 字段，这是实现增量同步最直接的依据。关键不是“有没有”，而是“索引是否有效”和“边界是否严谨”。

• 必须给时间字段建索引，否则每次查都全表扫描，增量变慢量
• 同步时要用 WHERE updated_at > '2025-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 > '2025-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）代替时间戳做精确锚点。