跨库对比禁用IN/NOT IN主键校验，须用NOT EXISTS或LEFT JOIN并确保远端索引、pushdown配置；字段比对需COALESCE空值、对齐聚合粒度、浮点用ABS容差。
跨库对比不能直接用 IN 或 NOT IN 做主键校验
MySQL 8.0+ 支持 FEDERATED 引擎，但默认关闭；PostgreSQL 用 postgres_fdw，SQL Server 用链接服务器——这些都不是“天然跨库”，得先建外部对象。一旦漏掉这步，SELECT * FROM db1.table1 WHERE id NOT IN (SELECT id FROM db2.table1) 会直接报错 Unknown database 'db2'（MySQL）或 invalid schema name（PostgreSQL）。更隐蔽的问题是：即使语法通过，NOT IN 遇到子查询返回 NULL，整行被静默过滤，导致漏差数据。
- 优先改用
NOT EXISTS，它对NULL不敏感，语义更可靠 - 确保子查询只
SELECT 1或主键字段，避免传输冗余列 - 如果目标库不支持跨库语法（如 SQLite），必须换方案：导出 CSV + 外部脚本比对
EXISTS 和 LEFT JOIN 在跨库场景下的性能分水岭
当你要查 “A 库里有、B 库里没有” 的记录时，NOT EXISTS 写法看着简洁，但实际执行依赖数据库是否能把子查询下推到远端执行。比如 MySQL 连接 PostgreSQL 时，若没配置好 postgres_fdw 的 pushdown 选项，NOT EXISTS 会把整个 B 库表拉到本地再过滤，IO 爆涨。
- 用
LEFT JOIN显式控制连接时机，例如：SELECT a.* FROM db1.orders a LEFT JOIN db2.orders b ON a.id = b.id WHERE b.id IS NULL - 确认远端库的索引已建在关联字段上（如
db2.orders(id)），否则 JOIN 会全表扫 - 某些数据库（如 SQL Server）对跨库
LEFT JOIN自动加分布式事务开销，此时反而是分批TOP 1000+NOT EXISTS更稳
字段级一致性校验必须对齐聚合粒度和空值处理
跨库比对不只是看“有没有”，还要核“对不对”。比如比对两个库中每日销售总额，(SELECT SUM(amount) FROM db1.sales WHERE date='2026-04-11') 和 (SELECT SUM(amount) FROM db2.sales WHERE date='2026-04-11') 直接相减，结果可能为 NULL ——只要任一库该日无记录，SUM() 返回 NULL，整个表达式崩掉。
- 统一用
COALESCE(SUM(amount), 0)把空转成 0，再做数值比较 - 如果 A 库是明细表、B 库是汇总表，子查询必须带
GROUP BY对齐维度，否则一对多导致重复计数 - 浮点字段（如金额）别用
=判断，改用ABS(a - b) ，防止精度误差误报差异
相关子查询在跨库时极易触发全量拉取，务必提前压测
写 SELECT * FROM db1.users u WHERE NOT EXISTS (SELECT 1 FROM db2.users v WHERE v.email = u.email) 看似合理，但多数数据库不会把 u.email 参数化传给远端执行——而是把整个 db2.users 拉到本地，再逐行匹配。10 万用户 × 50 万远端记录 = 50 亿次比对，内存直接 OOM。
- 改写为两阶段：先
SELECT email FROM db1.users导出本地临时表，再用WHERE email NOT IN (SELECT email FROM local_temp)查远端 - 或者反向操作：把远端关键字段（如 email）同步到本地缓存表，加索引后走
LEFT JOIN - 上线前必须用真实数据量压测，观察执行计划里是否有
Remote Scan或Foreign Scan被标记为“Materialize”
跨库子查询最危险的地方不在语法，而在执行路径不可见——你以为它在远端算，其实它在本地拉；你以为它走索引，其实它全表扫。每次写完都得看执行计划，而不是只看结果对不对。
