用update_time做增量同步是最常用方案，核心是每次只拉取比上次同步时间戳更新的数据；需确保字段可靠、时区统一（推荐UTC）、位点持久化存储，并注意空值、精度、批量更新失效及跨天延迟等常见问题。
用更新时间（update_time）做增量同步，是SQL数据同步中最常用也最实用的方案之一。核心思路是：每次只拉取比上次同步时间戳更新的数据，避免全量扫描，提升效率、降低数据库压力。
为什么选 update_time 而不是 create_time？
create_time 只能捕获新增，无法覆盖修改场景；而业务中大量数据会更新（如订单状态变更、用户资料修改），必须依赖 update_time 才能保证最终一致性。只要业务代码在每次更新时都正确维护该字段（推荐设为 ON UPDATE CURRENT_TIMESTAMP），它就是可靠的增量锚点。
同步逻辑怎么写？关键 SQL 模板
假设目标表为 red">orders，上一次同步的最大 update_time 是 '2024-06-10 14:22:33'：
SELECT * FROM orders WHERE update_time > '2024-06-10 14:22:33' ORDER BY update_time;
- 务必加 ORDER BY update_time，方便后续记录 checkpoint
- 生产环境建议加上 FOR UPDATE（若需强一致性且在事务内处理）
- 注意时区统一：数据库、应用、同步任务三端使用同一时区（推荐 UTC）
如何安全记录和管理同步位点？
不能靠内存或本地文件存上次时间——服务重启就丢。推荐两种方式：
- 独立元数据表：建一张 sync_checkpoint 表，字段含 task_name、last_update_time、updated_at，每次同步成功后用 REPLACE INTO 或 INSERT ... ON DUPLICATE KEY UPDATE 更新
- 外部存储：写入 Redis、ZooKeeper 或配置中心（如 Nacos），适合多实例并发同步场景，需配合分布式锁防重复消费
常见坑与应对建议
- 空 update_time：初始化数据或脏数据可能导致该字段为 NULL，查询时加 AND update_time IS NOT NULL
- 时间精度不一致：MySQL 5.6 默认秒级，5.7+ 支持毫秒（update_time DATETIME(3)），同步程序要匹配精度，否则漏数据
- 批量更新未触发：某些 ORM 或脚本可能绕过 update_time 自动更新机制，上线前务必验证更新逻辑是否真实生效
- 跨天延迟导致“跳过”：若同步任务失败数小时，下次直接取最新时间，可能跳过中间批次。建议采用“窗口重试”或保留最小 lag 容忍度（如最多回溯 5 分钟）
基本上就这些。update_time 方案简单直接，但细节决定成败——关键是字段可信、时间统一、位点可靠、异常可追溯。
