NOT EXISTS 比 NOT IN 更安全高效，因后者遇 NULL 返回空结果；EXCEPT 适合多字段差异对比但 MySQL 不支持；大表对比须加索引、LIMIT 和 EXPLAIN 验证执行计划。
子查询对比大表时，NOT EXISTS 通常比 NOT IN 更安全高效
直接用 NOT IN 查差异，只要任意一列含 NULL，整条结果就为空——这是线上查不到差异的最常见原因。而 NOT EXISTS 只关心是否存在匹配行，对 NULL 不敏感，执行计划也更容易走索引。
假设两张表 orders_2023 和 orders_2024 都有千万级数据，主键为 order_id：
SELECT o1.* FROM orders_2023 o1 WHERE NOT EXISTS ( SELECT 1 FROM orders_2024 o2 WHERE o2.order_id = o1.order_id );
-
NOT EXISTS子查询中必须写明确关联条件（如o2.order_id = o1.order_id），不能漏别名或写错字段 - 确保
orders_2024.order_id有索引，否则子查询会触发全表扫描，性能断崖式下跌 - 如果只比主键，用
LEFT JOIN ... IS NULL有时更快，但子查询逻辑更直观、易复用
对比多字段差异时，EXCEPT 比嵌套子查询更简洁且可读性强
当需要确认两表在 order_id、amount、status 三字段组合上是否完全一致，EXCEPT 是最直白的选择——它天然去重、自动忽略顺序，且多数引擎（PostgreSQL / SQL Server / DuckDB）对它做了优化。
(SELECT order_id, amount, status FROM orders_2023) EXCEPT (SELECT order_id, amount, status FROM orders_2024);
- MySQL 不支持
EXCEPT，得改用LEFT JOIN+IS NULL或NOT EXISTS模拟 -
EXCEPT要求两侧列数、类型严格一致；字符串比较注意隐式类型转换（比如VARCHAR和TEXT在某些版本可能不兼容） - 若表含大量重复行，
EXCEPT ALL（保留重复）和EXCEPT（默认去重）行为不同，务必确认业务语义
大表对比前必须加 LIMIT 和 EXPLAIN 验证执行计划
没加限制直接跑全量子查询，可能卡住连接、拖慢整个库。尤其当子查询未命中索引，EXPLAIN 里出现 type: ALL 或 rows 显示百万级扫描时，必须停手。
- 先试
EXPLAIN (ANALYZE)（PostgreSQL）或EXPLAIN FORMAT=JSON（MySQL 8.0+），看子查询是否走了索引扫描（type: index或ref） - 首次执行加
LIMIT 100，确认结果逻辑正确再放开；生产环境建议用分页（如按order_id分段）+ 异步任务处理 - 避免在子查询里用函数包裹关联字段，例如
WHERE UPPER(o2.order_id) = UPPER(o1.order_id)，这会让索引失效
增量对比场景下，用时间戳字段 + 子查询比全量对比快一个数量级
如果两张表都有 updated_at 字段，且业务允许只查最近 7 天变动，就绝不要扫全表。子查询可以精准锚定活跃数据范围：
SELECT * FROM orders_2023
WHERE updated_at >= '2024-06-01'
AND NOT EXISTS (
SELECT 1 FROM orders_2024
WHERE order_id = orders_2023.order_id
AND updated_at >= '2024-06-01'
);
- 时间范围过滤必须同时加在主表和子查询里，否则子查询仍可能扫全量
orders_2024 - 确保
updated_at和order_id有联合索引（顺序为(updated_at, order_id)），才能高效定位 - 跨年/跨月对比时，注意数据库时区设置，
'2024-06-01'默认是本地时区，可能漏掉 UTC 时间写入的数据
真正难的不是写出子查询，而是判断哪部分数据值得对比、哪些字段必须纳入、索引是否覆盖到位——这些决定跑十分钟还是跑两小时。
