用inner join比对两表数据是否完全相同，需在on子句中显式写出所有字段的null安全等值判断，如(t1.c = t2.c or (t1.c is null and t2.c is null))，缺一不可。
用 INNER JOIN 比较两表所有字段是否完全相同，关键在 WHERE 子句的等值组合
直接用 INNER JOIN 本身不会“自动对比所有字段”，它只按 ON 条件关联。要查出两表“完全相同”的行（即所有字段值都一致），必须显式写出每个字段的相等判断——哪怕字段名相同，也得逐个写 t1.col = t2.col。
常见错误是只写 ON t1.id = t2.id，这其实只是按主键关联，不是“内容完全相同”。真正需要的是：两行在所有业务字段上值完全一致（包括 NULL 的处理）。
- 如果两表结构完全一致（字段名、顺序、类型相同），可简化为逐字段
=判断 - NULL 值需特别注意：
NULL = NULL返回UNKNOWN，不是TRUE，所以必须用IS NOT DISTINCT FROM（PostgreSQL/SQL:2003 标准）或手写(t1.c IS NULL AND t2.c IS NULL) OR t1.c = t2.c - 字段太多时容易漏写或写错，建议先用元数据查出字段列表再拼接条件，避免肉眼比对
MySQL / SQL Server / SQLite 中如何安全处理 NULL 对比
这些数据库不支持 IS NOT DISTINCT FROM，必须手动展开 NULL 安全比较。例如两表都有 name、age、city 字段：
SELECT t1.* FROM table_a t1 INNER JOIN table_b t2 ON (t1.name = t2.name OR (t1.name IS NULL AND t2.name IS NULL)) AND (t1.age = t2.age OR (t1.age IS NULL AND t2.age IS NULL)) AND (t1.city = t2.city OR (t1.city IS NULL AND t2.city IS NULL));
漏掉任一字段的 NULL 处理，就会导致本该匹配的含 NULL 行被过滤掉。
- 别用
COALESCE(t1.col, '') = COALESCE(t2.col, '')替代——类型不匹配或默认值冲突时会误判（比如0和''都转成空字符串） - 数值型字段慎用
IFNULL/ISNULL转成 0，可能和真实 0 冲突 - 若字段允许 NULL，且业务上 NULL 有明确语义（如“未知”），那 NULL= NULL 就是合理匹配，不能简单跳过
PostgreSQL 可直接用 IS NOT DISTINCT FROM 简化逻辑
PostgreSQL 支持标准语法，让多字段 NULL 安全对比变得清晰可控：
SELECT t1.* FROM table_a t1 INNER JOIN table_b t2 ON t1.id IS NOT DISTINCT FROM t2.id AND t1.name IS NOT DISTINCT FROM t2.name AND t1.amount IS NOT DISTINCT FROM t2.amount;
这个写法语义明确：只要两值“逻辑上相等”（包括都是 NULL），就视为匹配。
- 性能上和手写
OR条件基本一致，优化器能识别并生成合理执行计划 - 但注意：不能用于索引字段的等值查询优化（
IS NOT DISTINCT FROM不走 B-tree 索引的等值路径），大数据量时建议先加复合索引覆盖所有参与对比的字段 - 如果只关心部分字段（比如忽略更新时间戳），就只列那些字段，别把
updated_at这类必然不同的字段加进去
更可靠的做法：用 CHECKSUM 或 HASH 避免字段爆炸式条件
当字段数超过 10 个，手写所有 = 或 IS NOT DISTINCT FROM 极易出错。此时可考虑基于行内容生成哈希值再对比：
- PostgreSQL：用
md5(row(t1.*)::text)（注意row()包含 NULL，::text序列化稳定） - SQL Server：用
BINARY_CHECKSUM(*)（但注意它对 NULL 敏感，且不同版本行为可能变化） - MySQL：8.0+ 可用
SHA2(CONCAT_WS('|', t1.col1, t1.col2, ...), 256)，但需确保分隔符不会出现在原始数据中
哈希法快且简洁，但有两个硬伤：一是哈希碰撞虽概率极低，但在校验场景下不能完全排除；二是无法直观看出哪几个字段不一致——如果目标是“定位差异”，哈希法只能告诉你“有差异”，还得回退到字段级对比。
真正容易被忽略的，是字段顺序和类型隐式转换带来的陷阱：比如 t1.status CHAR(1) 和 t2.status VARCHAR(10) 在 JOIN 时可能因尾部空格或隐式截断导致误判，这种问题不会报错，只会静默漏掉匹配行。
