EXISTS 通常比 IN 更快，因其可提前终止；IN 需物化子查询结果，开销更大，且受 NULL 影响语义不同；ANY/ALL 在 PostgreSQL 中常被优化为 EXISTS，性能相近，但 MySQL 对相关子查询支持有限。
EXISTS 为什么通常比 IN 更快
核心在于执行逻辑不同：EXISTS 只需找到子查询中任意一行匹配就返回 true，可提前终止；而 IN 在大多数数据库（如 PostgreSQL、MySQL 5.7+）中会先物化子查询结果（尤其当子查询含聚合或关联时），再做哈希查找或循环比较，内存和 CPU 开销都更高。
常见错误现象：IN 子查询返回 NULL 时整个表达式结果为 UNKNOWN（即不匹配），而 EXISTS 不受 NULL 影响——这是语义差异，但常被误认为“性能问题”。
- 使用场景：主表小、子表大，且只需判断存在性（如“查所有有订单的客户”）→ 优先用
EXISTS - 参数差异：若子查询含
SELECT *或SELECT 1，对EXISTS性能无影响；但IN的子查询列必须是单列，且类型需兼容 - PostgreSQL 中开启
enable_hashjoin = off可能迫使IN走嵌套循环，进一步拖慢
ANY/ALL 在 PostgreSQL 中的实际行为
ANY 和 ALL 是 SQL 标准语法，在 PostgreSQL 中会被优化器转为 EXISTS 或 NOT EXISTS 形式（尤其是配合 =、 等操作符时），所以性能通常接近 EXISTS，而非 IN。
但注意：如果写成 col = ANY(ARRAY[...])，PostgreSQL 会走数组扫描，比子查询更快；而 col = ANY(SELECT id FROM t) 才触发子查询优化路径。
- 使用场景：需要带比较运算符的集合判断（如“价格低于任意热门商品”）→ 用
比IN+ 额外WHERE更简洁且易优化 - 性能陷阱：MySQL 不支持
ANY/ALL子查询中的相关字段（correlated subquery），PostgreSQL 支持但可能无法下推 join 条件，导致重复执行子查询 -
ALL对空集返回 true（三值逻辑），和NOT EXISTS行为一致；但新手常误以为它等价于 “全部非空”，实际不是
IN 在 MySQL 8.0+ 的优化变化
MySQL 8.0 引入了 SEMIJOIN 优化策略，默认将 IN 子查询重写为半连接，性能可逼近 EXISTS。但该优化仅在子查询不包含 GROUP BY、DISTINCT、LIMIT 或外部引用（correlation）时生效。
容易踩的坑：IN 列表项超过 1000 个时（如 id IN (1,2,...,1200)），MySQL 会退化为逐项比较，甚至触发 max_allowed_packet 截断；而 EXISTS 始终走索引查找。
- 配置项：
optimizer_switch='semijoin=on'必须启用（默认开启），否则回退到旧版嵌套循环 - 使用场景：固定小列表（IN 可读性更好；动态大结果集 → 改用
EXISTS或临时表 - EXPLAIN 中看到
Using where; Using index for group-by之类提示，往往意味着IN未走 SEMIJOIN，得检查子查询结构
子查询是否相关，直接决定执行计划走向
所谓“相关子查询”，是指子查询里引用了外部查询的列（如 WHERE id IN (SELECT user_id FROM orders WHERE orders.user_id = users.id)）。这类子查询在多数数据库中无法物化，只能对外部行逐行执行——此时 EXISTS 和 IN 的性能差异缩小，但 EXISTS 仍略优，因少一次去重和 NULL 检查。
最隐蔽的问题：某些 ORM（如 Django ORM 的 __in）在生成子查询时，会无意引入相关性（比如加了 ORDER BY 或 LIMIT），导致优化器放弃 SEMIJOIN 或物化，最终变慢。
- 验证方法：用
EXPLAIN ANALYZE（PostgreSQL）或EXPLAIN FORMAT=TREE（MySQL 8.0+）看子查询是否标记为dependent subquery或Materialize - 修复建议：把相关子查询拆成 JOIN，或用 CTE 预先物化非相关部分
- 别依赖“写法看起来一样”——
IN和EXISTS在执行计划里可能是完全不同的算子树
