大数据量下用EXISTS代替IN能提升数倍到数十倍性能，如生鲜电商实测4.8秒→0.9秒；核心因EXISTS采用短路验证、不加载全量结果，而IN需先物化子查询结果集，易致内存溢出与IO飙升。
优先看执行计划，而不是凭经验选 EXISTS 或 IN；但多数生产场景下，EXISTS 更安全、更可控。
子查询返回大量数据时，无条件选 EXISTS
比如子查询从订单表查出 20 万条 user_id，主表是用户表（10 万行），用 IN 会先全量加载这 20 万 ID 到内存或临时文件，再逐行匹配——容易触发磁盘溢出、IO 飙升。而 EXISTS 对每个用户只在订单表索引中找一次，找到即停。
- 必须确保子查询关联字段（如
order.user_id）上有索引，否则EXISTS也会退化为全表扫描 -
EXISTS子查询里写SELECT 1、SELECT NULL或SELECT *效果一样，数据库不取值，只判是否存在 - PostgreSQL 默认对
EXISTS启用 Semi-Join 优化，MySQL 8.0+ 也支持，但老版本需确认是否开启semijoin优化开关
子查询结果极小（几十行内）且稳定，IN 更轻量
例如 WHERE status IN (SELECT code FROM sys_status WHERE category = 'order')，而 sys_status 全表才 12 行，这时 IN 会被优化器转成哈希查找，主表走一次全扫描 + 哈希匹配，比 EXISTS 的 10 万次独立子查询调用更省。
- 务必确认子查询不含
NULL：一旦SELECT code返回NULL，整个IN表达式变成UNKNOWN，结果集为空——这不是 bug，是 SQL 三值逻辑的必然表现 - 如果业务上允许，加
WHERE code IS NOT NULL是最直接的补救 - 这种场景下，
IN (1, 2, 3)这类字面量列表比子查询更快，无需优化器介入
遇到 NOT IN，立刻换成 NOT EXISTS
NOT IN 在子查询含任意 NULL 时直接失效，哪怕只有一行是 NULL，整条语句查不到任何数据。而 NOT EXISTS 完全不受影响，语义清晰，还能走索引。
- 错误写法：
WHERE user.id NOT IN (SELECT user_id FROM order) - 正确改写：
WHERE NOT EXISTS (SELECT 1 FROM order WHERE order.user_id = user.id) - MySQL 5.7+ 虽有物化优化，但遇上
ORDER BY或LIMIT就可能失效，NOT EXISTS更可靠
别把子查询硬塞进 WHERE，考虑派生表或 JOIN
当子查询逻辑复杂（带 GROUP BY、DISTINCT、聚合函数），或需要复用结果时，硬套 IN/EXISTS 容易让优化器放弃重写，甚至重复执行子查询。
- 更稳的做法：把子查询拎出来作为派生表（
FROM (SELECT ...) AS tmp），再和主表JOIN - PostgreSQL 默认物化派生表，MySQL 8.0+ 默认尝试内联（
derived_merge=on），但遇聚合就禁用，所以显式控制更安心 - 如果派生表结果固定且不大（如配置项），建
TEMPORARY TABLE并加索引，比反复跑子查询强得多
真正决定快慢的从来不是语法本身，而是执行计划里有没有走索引、有没有避免全表扫描、有没有被优化器误判为不可下推的谓词——所以每次改写后，一定跑一遍 EXPLAIN (ANALYZE, BUFFERS)，尤其注意 Rows Removed by Filter 和 Shared Hit Blocks 这两项。
