说实话，NOT IN在跨表行级对比时是个大坑——只要子查询里带回来一个NULL，整个条件就莫名其妙变成UNKNOWN，结果本该出现的行全被过滤掉了。这不是什么玄学bug，而是SQL三值逻辑的硬规则。解决方案其实很明确：换成NOT EXISTS配合相关子查询，同时要确保关联字段不能为NULL、类型一致、索引到位。

跨表做行级对比，直接拼IN或等号？不行。必须上EXISTS或NOT EXISTS配合相关子查询，否则一个NULL就能让你丢数据，字段类型隐式转换也会静默失败，查出来的结果根本不可信。

为什么NOT IN在行级对比中会丢数据

问题就出在这里：只要子查询返回了哪怕一个NULL（比如远端表的主键字段允许为空），整个NOT IN条件瞬间变成FALSE，本该被选出的行全被干掉了。这不是数据库的毛病，是SQL三值逻辑的必然结果。

• 举个典型场景：SELECT * FROM orders WHERE order_id NOT IN (SELECT order_id FROM archive_orders) —— 如果archive_orders.order_id里存在NULL，结果集直接为空
• 就算你拍胸脯说现在远端没有NULL，也千万别依赖这个假设：DDL变更、ETL异常、权限限制，哪个都可能让子查询偷偷返回NULL
• IN其实也一样危险：WHERE id IN (SELECT id FROM remote)遇到NULL虽然不会丢数据，但语义已经不是“存在匹配”，而是“等于某个非空值”，区别很大

EXISTS子查询怎么写才真正做行级对比

相关子查询必须绑定外层字段，而且只查1或者主键——别把全字段都扔进子查询，否则数据传输量直接爆炸。同时要主动处理空值和类型对齐。

• 标准写法：SELECT * FROM t1 WHERE NOT EXISTS (SELECT 1 FROM t2 WHERE t2.id = t1.id AND t2.status = t1.status)
• 千万别在子查询里写SELECT *：数据库可能把远端全字段拉到本地再过滤，跨库场景下IO瞬间爆炸
• 如果t1.status是VARCHAR，t2.status是INT，乖乖加CAST(t2.status AS CHAR)，或者用COALESCE统一兜底
• 字段里可能有NULL？用COALESCE(t1.field, 'N/A') = COALESCE(t2.field, 'N/A')代替直接等值，避免被NULL破坏

跨库场景下相关子查询的性能陷阱

数据库能不能把EXISTS子查询下推到远端执行，直接决定了这个查询是秒出结果还是等到超时。这取决于外部数据源的配置，跟SQL本身没太大关系。

• MySQL + FEDERATED：默认不搞pushdown，EXISTS会把整张远端表拉到本地再匹配，慢到怀疑人生
• PostgreSQL + postgres_fdw：要主动设置push_down = true，而且远端表id字段必须建索引，不然照样全量拉取
• 更稳妥的替代方案是LEFT JOIN + WHERE t2.id IS NULL：语法上多写几行，但连接策略更可控，不容易踩坑
• 压测时一定要开EXPLAIN检查执行计划，重点关注有没有出现Remote Subquery之类的字样——没看到就说明没下推

行级对比真正的难点从来不在语法，而在于你得同时盯住三件事：空值语义、字段类型兼容性、远端执行能力。少盯一个，结果就不可信。