not in在行级对比中会丢数据，因为只要子查询返回任意null，整个条件即为unknown而被where过滤；必须改用not exists配合相关子查询，并确保关联字段非空、类型一致、索引有效。
跨表行级对比不能靠IN或=直接比，必须用EXISTS或NOT EXISTS配合相关子查询，否则遇到NULL就漏数据、字段类型隐式转换就静默失败。
为什么NOT IN在行级对比中会丢数据
只要子查询返回任意一个NULL（比如远程表某主键字段允许为空），整个NOT IN条件就永远为FALSE，导致本该被选出的行被过滤掉。这不是bug，是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和t2.status一个是VARCHAR、一个是INT，加CAST(t2.status AS CHAR)或统一用COALESCE兜底 - 字段含
NULL时，用COALESCE(t1.field, 'N/A') = COALESCE(t2.field, 'N/A')代替直接等值
跨库场景下相关子查询的性能陷阱
数据库是否能把EXISTS子查询下推到远端执行，直接决定查询是秒出还是超时。这取决于外部数据源配置，不是SQL本身能控制的。
- MySQL +
FEDERATED：默认不pushdown，EXISTS会把整张远端表拉过来匹配 - PostgreSQL +
postgres_fdw：必须设push_down = true且远端id字段有索引，否则一样全量拉取 - 更稳的替代方案：
LEFT JOIN+WHERE t2.id IS NULL，虽然语法稍长，但连接策略更可控 - 压测时一定要开
EXPLAIN看执行计划，重点确认Remote Subquery或类似字样是否出现
行级对比真正的难点不在语法，而在你得同时盯住三件事：空值语义、字段类型兼容性、远端执行能力。少盯一个，结果就不可信。
