LEFT JOIN配合WHERE右表主键IS NULL能精准捕获增量数据，因其基于主键物理比对识别“源表有、目标表无”的记录，不依赖时间戳或版本号，结果更可靠；必须用IS NULL而非= NULL，且需确保右表关联字段有索引、NULL值场景需显式处理。
LEFT JOIN 配合 WHERE 右表主键 IS NULL 是最可靠、最通用的增量识别方式，尤其适合上游无时间戳或字段不准的场景。
为什么 LEFT JOIN 能精准捕获增量数据
增量数据的本质是「源表有、目标表没有」的记录。LEFT JOIN 会保留左表（源表）全部行，右表（目标表）匹配不上时对应字段为 NULL；再用 WHERE t.id IS NULL 过滤，就只留下那些在目标表里完全缺失的行——这才是真正需要同步的增量。
它不依赖时间字段或版本号，避免了因时间不同步、批量导入导致的时间乱序、NULL 时间值等问题。但必须强调：IS NULL 不能写成 = NULL，后者永远返回 false。
- 常见错误：漏掉
WHERE t.id IS NULL，结果返回源表全量，误以为是增量 - 复合主键场景下，
ON条件必须完整覆盖所有业务主键字段，例如s.order_id = t.order_id AND s.sku_code = t.sku_code - 若关联字段本身允许
NULL（如email），默认等值匹配会跳过所有NULL行，导致漏同步
NULL 字段导致匹配失效怎么办
当 ON s.email = t.email 遇到 NULL 值时，数据库按 SQL 标准返回 UNKNOWN，不视为匹配成功。这意味着含 NULL 邮箱的用户永远不会被识别为“新增”。
解决方法是显式补全 NULL 匹配逻辑：
SELECT s.* FROM source_user s LEFT JOIN target_user t ON (s.email = t.email OR (s.email IS NULL AND t.email IS NULL)) WHERE t.email IS NULL;
注意：不能只写 OR (s.email IS NULL AND t.email IS NULL)，否则会破坏等值匹配前提，引发笛卡尔积风险。
- 多个可能为
NULL的字段（如phone,address）需逐个展开判断，语句迅速膨胀 - 此时建议改用
NOT EXISTS更清晰，可读性和维护性更好 - PostgreSQL 用户可用
s.email IS NOT DISTINCT FROM t.email简化写法
性能差？先查右表索引和统计信息
LEFT JOIN 查差集的性能瓶颈几乎总在右表（target）。即使加了 WHERE t.id IS NULL，优化器仍可能对右表做全表扫描——尤其是右表缺少关联字段索引，或统计信息陈旧时。
务必确认右表连接字段已建索引：
ALTER TABLE target_user ADD INDEX idx_user_id (user_id);
- 索引字段选择要严格匹配
ON中的右表列，例如ON s.id = t.id→ 给t.id建索引 - 若使用复合主键，索引也需是复合的，且字段顺序与
ON条件一致 - 执行
ANALYZE TABLE target_user;更新统计信息，帮助优化器选对执行计划 - EXPLAIN 执行计划中若出现
type: ALL或rows显示扫描全表，基本可判定索引未生效
连表更新同步时的 JOIN 写法陷阱
识别出增量后，常用 UPDATE ... JOIN 直接写入目标表。MySQL 支持标准语法：
UPDATE target_user t JOIN source_user s ON t.user_id = s.user_id SET t.name = s.name, t.email = s.email WHERE s.updated_at > '2026-06-01';
但这里容易忽略两个关键点：
-
UPDATE ... JOIN默认是 INNER JOIN 语义，只更新已有记录；要实现“有则更新、无则插入”，得配合INSERT ... ON DUPLICATE KEY UPDATE或MERGE（MySQL 8.0.19+） - 多表 JOIN 更新时，
SET子句只能引用JOIN中明确列出的表，不能跨层引用子查询别名中的字段 - WHERE 条件若放在子查询外（如驱动表过滤），可能意外剪枝导致部分增量丢失；应尽量把过滤条件下推到源表子查询内
真正难的不是写出语法，而是确保每一步的语义边界清晰：LEFT JOIN 识别谁该进，JOIN UPDATE 决定怎么改，而索引和 NULL 处理决定了它跑不跑得动。
