NOT IN 遇子查询含 NULL 时返回空结果是 SQL 三值逻辑必然表现，非 Bug；NOT EXISTS 因只判断存在性、不受 NULL 影响且支持短路，更可靠高效。
直接用 NOT IN 校验关联完整性，只要子查询字段含 NULL，结果就全空——这不是 bug，是 SQL 三值逻辑的必然表现。必须改用 NOT EXISTS 或显式处理 IS NULL。
为什么 NOT EXISTS 比 NOT IN 更稳
NOT IN 遇到子查询返回任意一个 NULL，整行判定为 UNKNOWN，被 WHERE 过滤掉，导致“孤儿数据”完全漏检；NOT EXISTS 只关心是否存在匹配行，NULL 不影响逻辑判断，天然短路，性能也更可控。
- 错误写法：
WHERE order_id NOT IN (SELECT order_id FROM shipments)—— 若shipments.order_id有NULL，结果恒为空 - 正确写法：
WHERE NOT EXISTS (SELECT 1 FROM shipments WHERE shipments.order_id = orders.order_id) - 子查询里只
SELECT 1，避免传输冗余字段 - 外层表字段（如
orders.order_id）必须出现在子查询WHERE条件中，否则变成非相关子查询
LEFT JOIN + IS NULL 替代 NOT EXISTS 的坑
语义等价，但执行计划可能不同：某些优化器对 NOT EXISTS 更友好，尤其在大表上；而 LEFT JOIN 易受索引缺失或类型不一致拖累。
- 必须确保
JOIN字段两边类型、长度、是否允许NULL完全一致，否则隐式转换会让索引失效 - 写法示例：
SELECT o.order_id FROM orders o LEFT JOIN shipments s ON o.order_id = s.order_id WHERE s.order_id IS NULL - 别写成
WHERE s.* IS NULL—— 语法错误 - 也别漏掉
IS NULL判断，直接WHERE s.order_id = NULL永远不成立
跨表字段值一致性校验怎么防坑
比如核对订单头金额和明细总和是否相等，不能直接 SUM() 对比，得先对齐聚合维度，再处理空值和浮点误差。
- 明细表
item_amount允许NULL？得用SUM(COALESCE(item_amount, 0))，否则SUM()会跳过整行 - 汇总表字段名、类型、精度必须和明细侧严格一致；字符型字段要统一
COLLATION，否则'ABC'和'abc'可能被当成相等 - 浮点数比对别用
=，改用ABS(a - b) < 0.01；整数字段则可直接!=
真正难的不是写出能跑的 SQL，而是确认「没漏掉任何一种不一致场景」
缺失行、值不等、NULL 处理差异、字符集隐式转换、聚合粒度错位……每种都得单独覆盖，少一个就等于放过了脏数据。特别是当校验逻辑嵌套多层或涉及软删除、状态码映射、时区转换时，EXISTS 的相关性、子查询的执行顺序、以及数据库对 LATERAL 或递归 CTE 的支持程度，都会成为实际落地时最隐蔽的断点。
