update_time字段必须满足四硬性条件：真实、非空、带索引、被业务代码可靠更新；类型须为TIMESTAMP（SQL Server/Oracle）或DATETIME(3)（MySQL 5.7+）；须显式设置ON UPDATE CURRENT_TIMESTAMP等自动更新逻辑；且严禁NULL，所有UPDATE操作必须实际修改该字段。
必须有可追踪的变更字段，且 update_time 字段必须真实、非空、带索引、被业务代码可靠更新——缺一不可，否则增量同步就是定时漏数据。
update_time 字段必须满足哪些硬性条件？
不是“加了字段就万事大吉”，生产环境里大量同步失败源于字段本身不达标：
-
update_time必须定义为TIMESTAMP（SQL Server/Oracle）或DATETIME(3)（MySQL 5.7+），避免秒级精度丢失毫秒级变更 - 必须显式设置自动更新逻辑：
ON UPDATE CURRENT_TIMESTAMP（MySQL）、DEFAULT GETDATE() FOR update_time+ 触发器或 ORM 显式赋值（SQL Server） - 业务代码中所有
UPDATE操作必须实际修改该字段——比如 Django 的save(update_fields=['name'])会绕过时间戳更新，导致后续同步跳过整条记录 - 字段不能允许 NULL：
ALTER TABLE orders ALTER COLUMN update_time SET NOT NULL，否则WHERE update_time > @last_time会永远过滤掉 NULL 行
为什么 WHERE update_time > @last_time 还会漏数据？
常见错误不是写错 SQL，而是没理解时间窗口和执行节奏的耦合关系：
- 硬写固定偏移（如
SYSDATE - 1/24）必然漏数据：任务延迟 2 小时，中间变更就彻底丢失 -
@last_time必须来自上一次成功同步的MAX(update_time)，而不是当前系统时间减去间隔 - 同步脚本必须在事务提交后立即持久化新位点到控制表，例如：
UPDATE sync_control SET last_sync_time = @current_max_time WHERE table_name = 'orders' - 若同步中途失败，
@last_time不能回退——要靠控制表里的last_handle_time判断是否重试，否则可能重复插入或跳过变更
嵌套查询中时间过滤放错位置，性能差还语义错
多表关联同步时，时间条件放哪，直接决定是否走索引、是否漏行：
- 错误写法：
SELECT * FROM orders WHERE id IN (SELECT order_id FROM order_items WHERE updated_at > @t)—— 子查询独立执行，updated_at索引失效；更糟的是，订单主表更新但子项未动，整条订单就被丢弃 - 正确做法：时间过滤必须落在主表字段上，子表仅用于存在性判断：
SELECT o.* FROM orders o WHERE o.update_time > @t AND EXISTS (SELECT 1 FROM order_items i WHERE i.order_id = o.id AND i.update_time > @t) - 必须给子表建复合索引：
CREATE INDEX IX_order_items_orderid_updated ON order_items(order_id, update_time)，否则EXISTS仍会全表扫描 - 严禁在
USING子句中依赖参数兜底——MERGE INTO target USING (SELECT * FROM src WHERE update_time > @t) AS src中，若@t为 NULL，整个子查询为空，WHEN NOT MATCHED就会把源表全量插入
DELETE 怎么同步？MERGE 不管删，得单独补
MERGE 只处理 INSERT/UPDATE，物理删除必须显式捕获并同步，否则目标表迅速积累孤儿数据：
- 不能依赖 “源表没了，目标表就该删”——得有明确依据，比如用 CDC 日志、或基于删除标记字段（
is_deleted = 1）+ 删除时间 - 若用时间戳方案，需额外查出“上次同步后被删的主键”：
SELECT id FROM [备用服务器].DB.dbo.目标表 t WHERE NOT EXISTS (SELECT 1 FROM 主服务器.DB.dbo.目标表 s WHERE s.id = t.id) AND t.update_time > @last_time - 这个查询必须加
AND t.update_time > @last_time，否则会误删那些早于上次同步时间、但尚未同步到目标库的“旧记录” - DELETE 操作本身也要进事务，并记录日志——失败时能定位是哪条记录删不动，而不是静默跳过
最易被忽略的一点：同步位点（last_sync_time）绝不能存在局部变量或内存里，每次调度都是新会话，断点续传全靠控制表；而控制表本身，必须有唯一约束和事务保护，否则并发任务会互相覆盖位点。
