LEFT JOIN + IS NULL 比 NOT IN 更可靠，因 NOT IN 遇右表 NULL 即返回空结果，而 LEFT JOIN 保留左表全量并用 WHERE b.id IS NULL 精准筛选缺失记录。
为什么用 LEFT JOIN + IS NULL 比 NOT IN 更可靠
直接用 NOT IN 查“只在表A有、表B没有”的记录，很容易漏数据——只要 table_b.id 里有一个 NULL，整个查询就返回空结果。这是 SQL 三值逻辑的坑，不是 bug，但实际中几乎总踩中。
更稳的做法是用 LEFT JOIN 配合 IS NULL 判断右表缺失：
SELECT a.* FROM snapshot_a a LEFT JOIN snapshot_b b ON a.id = b.id WHERE b.id IS NULL;
-
LEFT JOIN保证左表所有行都保留，右表匹配不到的字段全为NULL -
WHERE b.id IS NULL精准筛出“在 A 有、在 B 无”的行，不受NULL干扰 - 如果两表都有主键或唯一业务键（比如
order_id），务必在ON条件里用它对齐，别用模糊字段（如name）
对比字段级变更：用 CONCAT 或 HASH 避免逐列 IS NULL
光知道“哪条记录新增/删除”不够，常需定位“哪些字段值变了”。手动写 a.col1 != b.col1 OR a.col2 != b.col2 OR ... 不仅啰嗦，还会因 NULL 导致条件失效（NULL != 'x' 是 UNKNOWN，不进 WHERE）。
推荐两种轻量方案：
- 用
CONCAT拼接非空字段（MySQL/PostgreSQL 支持CONCAT_WS自动跳过NULL）：CONCAT_WS('|', a.name, a.status, a.updated_at)vsCONCAT_WS('|', b.name, b.status, b.updated_at) - 更健壮的做法是生成行级哈希（如 PostgreSQL 的
md5(row_to_json(b)::text)，MySQL 8.0+ 可用SHA2(CONCAT(...), 256)），再比哈希值是否相等 - 注意：时间字段要统一时区和精度（比如都转成
YYYY-MM-DD HH:MM:SS字符串再拼），否则看似相同的时间会因毫秒差异被判定为变更
性能关键：JOIN 前必须加 WHERE 过滤快照时间范围
历史快照表往往按天/小时分区，但若没显式限定时间，数据库可能扫全表。即使加了索引，JOIN 本身也会放大 I/O —— 100 万行 × 100 万行的笛卡尔积风险真实存在。
- 务必在
JOIN子句外，用WHERE先缩小左右表数据集：WHERE a.snapshot_date = '2024-05-01' AND b.snapshot_date = '2024-05-02' - 确保
snapshot_date和关联键（如id）上有联合索引，例如INDEX idx_date_id (snapshot_date, id) - 如果快照表极大（>1 亿行），考虑先用
CREATE TEMP TABLE抽出两个子集再 JOIN，避免优化器误判执行计划
小心隐式类型转换导致 JOIN 失效
两张快照表若来自不同系统，同一字段类型可能不一致：比如 user_id 在 A 表是 VARCHAR(32)，在 B 表是 BIGINT。此时 ON a.user_id = b.user_id 看似正常，实则触发隐式转换——B 表字段全转成字符串再比，索引失效，且可能因补零、截断引发误匹配（如 '00123' 和 123 被认为相等）。
- 用
DESCRIBE或\d table_name检查两表对应字段的精确类型 - 显式转换确保一致：
ON a.user_id = CAST(b.user_id AS VARCHAR)（PostgreSQL）或ON a.user_id = CONVERT(VARCHAR, b.user_id)（SQL Server） - 字符串类 ID 尽量全程保持字符类型，别存成数字再转回——这是历史包袱最易出问题的地方
真正难的不是写出差异 SQL，而是确认两表的业务含义对齐、空值约定一致、类型定义没漂移。跑出结果后，一定抽样核对几条“变更”记录的手动验证结果。
