UNION ALL + GROUP BY + HAVING 是最直接的全量差异定位方式，适用于结构兼容的表，通过拼接后按所有比对字段分组并筛选 COUNT(*) = 1 的行来识别单边存在记录，无需主键或同名字段，但要求 SELECT 列严格对齐、显式写出 GROUP BY 字段、注意 NULL 和字符串隐式转换问题。
UNION ALL + GROUP BY + HAVING 是最直接的全量差异定位方式
只要两张表结构兼容（列数、类型、顺序可对齐），UNION ALL拼接后按所有比对字段分组，再用HAVING COUNT(*) = 1就能筛出只在其中一张表出现的行。它不依赖主键，也不要求字段名一致，只要 SELECT 列能一一对应即可。
- 常见错误现象：
Column count doesn't match或结果为空但实际有差异——多半是SELECT的列没对齐，或漏写了GROUP BY后的关键字段 - 必须显式写出所有参与比对的列，不能写
*（除非两张表字段完全一致且顺序相同） -
GROUP BY的字段必须和SELECT中的非聚合列完全一致，否则 MySQL 8.0+ 会报错 - 字符串字段注意隐式类型转换：比如
CHAR和VARCHAR末尾空格处理不同，可能让本该相同的行被当成差异 -
NULL值在GROUP BY中被视为相同，但多NULL行会导致COUNT(*)大于 1，从而漏掉真实差异
LEFT JOIN + IS NULL 模拟 EXCEPT，适合单向差集
MySQL 不支持 EXCEPT，想取「表 A 有、表 B 没有」的数据，必须靠 LEFT JOIN + IS NULL 组合实现。核心是把待查差异行作为左表，右表按全字段关联，再筛出右表匹配为空的记录。
- 所有参与比对的字段都要出现在
ON子句中，否则WHERE b.xxx IS NULL判定会失效 - 字段允许
NULL时，a.col = b.col在任一端为NULL时结果恒为UNKNOWN，应改用a.col b.col（MySQL 的 NULL 安全等于） - 连接字段最好都有索引；若无联合索引，多字段
ON条件可能触发全表扫描 - 字符集或排序规则（
COLLATE）不一致会导致比较失败，执行前务必用SHOW CREATE TABLE核对各字段的COLLATE是否一致
为什么 NOT IN 和子查询容易出问题
NOT IN 看似简洁，但实际风险高：只要子查询返回任意一个 NULL，整个 NOT IN 结果恒为 FALSE 或 UNKNOWN，导致零行返回（静默失败）。
- 无法利用索引加速，尤其子查询结果大时性能断崖式下降
- 语义上它检查的是单字段值是否不在集合中，不适用于整行比对场景
-
EXISTS虽比NOT IN更安全，但仍需确保子查询中所有比对字段都参与关联条件，否则逻辑不等价
比对前必须明确“一行数据”的业务定义
差异判断粒度由 GROUP BY 或 JOIN 字段决定。比如比对配置表 config_standard_quality_control_item，常靠 defect_id, defect_name, type_id 联合唯一——少一个字段，就可能把两条逻辑不同的记录合并成一组，导致误判。
- 优先用主键或唯一索引的全部字段做分组/连接，最稳妥
- 避免用
update_time或created_at等时间戳字段参与比对，它们极易因同步延迟造成假差异 - 先确认业务上“一行数据”的定义，再反推需要参与分组或连接的字段
NULL 怎么算相等、字符集是否一致——这些细节不校验，再短的 SQL 也只会返回假阴性或假阳性。 
