exists 通常比 in 快，因其为半连接，匹配即止；in 需构建完整结果集再查找，且受 null 影响大、易全表扫描或生成临时表，但小列表时 in 更轻量。
EXISTS 为什么通常比 IN 快？
因为 EXISTS 是半连接（semi-join），只要子查询找到一条匹配就立刻返回 TRUE，不继续扫描；而 IN 在大多数数据库里会先执行子查询生成结果集，再做哈希查找或嵌套循环——如果子查询返回上万行，IN 就得多一次全量构建和去重（尤其含 NULL 时行为更复杂）。
但这个“通常”有前提：子查询字段有索引、外层表小、内层表大。如果反过来——外层表极大、子查询极小（比如 IN (1, 2, 3)），IN 反而更轻量。
-
EXISTS不受子查询中NULL值影响，语义稳定；IN遇到NULL会整体返回UNKNOWN，导致整行被过滤掉（容易漏数据） - MySQL 5.7+ 对
IN子查询做了物化优化，但仅限于简单子查询；一旦带GROUP BY或聚合，仍会退化为临时表 - PostgreSQL 的
IN和EXISTS在多数场景下优化器能自动等价转换，但显式写EXISTS更利于语义传达和避免误判
IN 在什么情况下会意外变慢？
最常见的是子查询返回 NULL，或者没走索引导致全表扫描。比如：SELECT * FROM orders WHERE customer_id IN (SELECT id FROM customers WHERE status = 'active')，如果 customers.status 没索引，子查询就扫全表，外层每行都触发一次（除非数据库优化掉了）。
- 子查询结果含
NULL：整个IN表达式逻辑失效，不是“慢”，而是查不到预期数据 - 子查询用了
DISTINCT或ORDER BY：强制生成临时表，内存/磁盘开销陡增 - MySQL 中子查询用了
LIMIT：直接报错This version of MySQL doesn't yet support 'LIMIT & IN/ALL/ANY/SOME subquery' - Oracle 旧版本对
IN列表长度超 1000 项会报ORA-01795: maximum number of expressions in a list is 1000
EXISTS 的正确写法和常见翻车点
核心是相关子查询必须关联外层——漏写 WHERE 关联条件，就会变成非相关子查询，性能暴跌甚至逻辑错误。比如把 EXISTS (SELECT 1 FROM logs l WHERE l.order_id = o.id) 错写成 EXISTS (SELECT 1 FROM logs l WHERE l.order_id = 123)，那就成了固定值判断，完全失去意义。
- 别在
EXISTS子查询里SELECT *：虽然不影响结果，但可能让优化器误判列依赖，改用SELECT 1或SELECT NULL - PostgreSQL 中，如果子查询只查主键且外键约束存在，
EXISTS可能被优化为索引仅扫描（Index Only Scan），IN则不一定 - SQL Server 里，
NOT EXISTS通常比NOT IN安全得多——后者只要子查询结果含一个NULL，整个结果集就为空
实际选型建议：看执行计划，别猜
没有银弹。同一句 SQL 在 MySQL、PostgreSQL、SQL Server 上的执行路径可能完全不同。比如 PostgreSQL 对 IN (subquery) 默认走 Hash Semi Join，而 SQL Server 可能选 Loop，这时数据分布就决定快慢。
- 用
EXPLAIN ANALYZE（PostgreSQL）、EXPLAIN FORMAT=JSON（MySQL 8.0+）或SET STATISTICS IO ON（SQL Server）看真实执行路径和行数预估 - 测试时禁用查询缓存（MySQL 加
SQL_NO_CACHE，PostgreSQL 设enable_seqscan=off临时验证索引有效性） - 如果子查询结果固定且很小（IN (1,2,3...)，比
EXISTS还少一次解析开销
真正卡住性能的，往往不是 EXISTS 或 IN 本身，而是外键缺失、统计信息过期、子查询里写了 LIKE '%xxx' 这种无法走索引的条件——这些地方才最该盯紧。
