LEFT JOIN比对历史表差异的核心是：先确保B表过滤条件放在ON而非WHERE中，避免NULL行被误滤；再用IS DISTINCT FROM或显式NULL判断比对字段；最后为JOIN字段建联合索引并取最新快照。

LEFT JOIN 时 WHERE 条件写错位置导致漏掉 NULL 行

比对历史表差异的核心逻辑是：找出 A 表有但 B 表没有的记录。用 LEFT JOIN 时，必须把 B 表的过滤条件放在 ON 子句里，而不是 WHERE。一旦写成 WHERE b.id IS NULL AND b.status = 'active'，就等于强制要求 b.status 为 'active'，而 b 行根本不存在（全是 NULL），结果整条记录被过滤掉——你想要的“缺失行”反而消失了。

正确做法是把 B 表的业务条件挪进 ON：

SELECT a.* 
FROM table_a a 
LEFT JOIN table_b b ON a.id = b.id AND b.status = 'active'
WHERE b.id IS NULL;

这样，LEFT JOIN 先按条件尝试匹配，再用 WHERE b.id IS NULL 拿到所有没匹配上的 a 行。

用 COALESCE 或 IS NULL 判断多字段是否完全一致

如果要找“内容不同”的行（不只是缺失），不能只靠主键，得逐字段比对。直接写 a.col1 != b.col1 OR a.col2 != b.col2 会有陷阱：任一字段为 NULL 时，比较结果恒为 UNKNOWN，整条逻辑失效。

安全写法是统一用 IS DISTINCT FROM（PostgreSQL）或模拟它（MySQL/SQL Server）：

• PostgreSQL 直接用：(a.col1, a.col2) IS DISTINCT FROM (b.col1, b.col2)
• 其他数据库改用：COALESCE(a.col1, '') != COALESCE(b.col1, '') OR COALESCE(a.col2, '') != COALESCE(b.col2, '')，但要注意空字符串和 NULL 语义是否等价
• 更稳妥的通用写法：(a.col1 != b.col1) OR (a.col1 IS NULL) != (b.col1 IS NULL)，显式拆解 NULL 判断

JOIN 前先加索引，否则大表比对会卡死

两张百万级历史表做 LEFT JOIN，没索引的话执行可能从秒级变成小时级。关键不是给主键建索引（通常已有），而是确保 ON 中用到的所有字段都参与了联合索引。

比如 ON a.id = b.id AND b.status = 'active'，b 表需要的不是单列 id 索引，而是 (id, status) 的联合索引（顺序不能反）；a 表若还有时间范围筛选，(id, updated_at) 也值得考虑。

执行前务必看 EXPLAIN 输出，确认是否走了索引。如果显示 type: ALL 或 rows 数量接近全表，说明索引没生效。

历史表时间戳不一致时，用子查询先取最新快照

历史表往往带 start_time/end_time 或 version 字段。直接拿全量 LEFT JOIN，会把所有版本都拉进来比对，结果爆炸且无意义。必须先各自聚合出“当前有效行”再 JOIN。

例如按 id 分组取最大 version：

SELECT * FROM table_a a1
WHERE a1.version = (
  SELECT MAX(a2.version) FROM table_a a2 WHERE a2.id = a1.id
);

然后把这个子查询作为临时表和 b 表 JOIN。如果数据量极大，建议把快照结果物化成临时表，避免重复计算。

真正难的不是语法，是搞清“你要比对的是哪一刻的状态”——这个前提错了，后面所有 LEFT JOIN 都在算错的东西。