左连接时右表时间戳过滤必须放在on子句而非where，否则会丢失左表无匹配的记录；需处理null值、时区差异及重复匹配问题。
左连接时右表时间戳过滤必须放在 ON 而非 WHERE
很多人写增量同步的 LEFT JOIN 时，习惯把右表的时间戳条件写在 WHERE 子句里，结果发现左表没匹配上的记录全丢了——这不是 LEFT JOIN，实际变成了 INNER JOIN。根本原因是 WHERE 会在连接后过滤，把右表为 NULL 的整行干掉。
正确做法是把右表的时间戳条件放进 ON 子句：
SELECT a.id, a.updated_at, b.data FROM orders a LEFT JOIN order_logs b ON a.id = b.order_id AND b.created_at >= '2024-06-01' -- ✅ 放在 ON 里 WHERE a.updated_at >= '2024-06-01';
-
AND b.created_at >= ...在ON中：保留所有左表记录，只限制右表匹配范围 - 若挪到
WHERE b.created_at >= ...：右表字段为 NULL 的行被直接剔除 - 注意：即使右表无索引，该条件仍影响连接基数，建议在
order_logs(order_id, created_at)上建联合索引
时间戳字段存在 NULL 值时的处理风险
如果右表的 created_at 允许为 NULL（比如历史脏数据或未补全日志），AND b.created_at >= 'X' 在 ON 中会自动跳过这些 NULL 行——它们不会参与匹配，但左表记录仍保留。这看似合理，实则可能掩盖数据缺失问题。
更稳妥的做法是显式排除 NULL：
... LEFT JOIN order_logs b ON a.id = b.order_id AND b.created_at IS NOT NULL AND b.created_at >= '2024-06-01'
- NULL 时间戳通常代表无效或未就绪数据，不应参与增量逻辑
- 某些数据库（如 PostgreSQL）对 NULL 比较行为严格，
NULL >= 'X'恒为 UNKNOWN，等价于 FALSE - MySQL 8.0+ 默认 SQL mode 下同样不匹配，但低版本兼容模式下行为可能不同，不可依赖
跨时区时间戳字段的同步陷阱
当左表和右表的时间戳存储在不同时区（例如左表用 UTC，右表用本地时区），直接比较会导致漏数据或重复。比如右表一条北京时间 2024-06-01 01:00 的记录，在 UTC 是 2024-05-31 17:00，若用 UTC 时间过滤就会丢掉。
解决方案取决于数据库能力：
- PostgreSQL：统一转成 UTC 再比，用
b.created_at AT TIME ZONE 'Asia/Shanghai' AT TIME ZONE 'UTC' - MySQL：用
CONVERT_TZ(b.created_at, '+08:00', '+00:00')（需确认系统时区配置生效） - 最稳方式：业务层保证所有时间戳存为 UTC，避免运行时转换开销和精度丢失
LEFT JOIN + 时间戳过滤后的 NULL 判断要小心
增量同步常需识别“右表无对应记录”的情况，典型写法是 WHERE b.id IS NULL。但若右表有多个满足时间条件的记录，LEFT JOIN 可能返回多行，导致左表被重复计数或误判。
两种常见应对策略：
- 加
DISTINCT或GROUP BY a.id去重（适合只需判断是否存在） - 改用
NOT EXISTS替代 LEFT JOIN（语义更清晰，且天然防重复）：WHERE NOT EXISTS (SELECT 1 FROM order_logs b WHERE b.order_id = a.id AND b.created_at >= '2024-06-01') - 若需取右表最新一条，应在 JOIN 前用子查询或窗口函数预聚合，而不是靠 LEFT JOIN 后再
MAX()
时间戳过滤看着简单，真正落地时，ON/WHERE 位置、NULL 处理、时区对齐、重复匹配这四点，任何一个疏忽都会让增量逻辑悄悄出错。
