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）时生效。
