exists 优先用于存在性判断场景，如外层表小、子查询有索引、需短路终止或涉及null安全时；in适用于子查询结果集小且为常量列表的情况。
EXISTS 通常比 IN 更快，尤其当子查询结果集大、外层表小，或子查询能利用索引时；但实际性能取决于数据分布、索引设计和执行计划，不能一概而论。
什么时候优先用 EXISTS
EXISTS 适合“是否存在匹配记录”的语义场景，数据库引擎可在找到第一条匹配行后立即停止扫描，具备短路特性。
- 子查询涉及大表，且有高效索引（如关联字段已建索引）
- 外层主表数据量较小，但需频繁判断存在性（例如：查所有有订单的客户）
- 子查询含复杂条件（JOIN、WHERE 过滤多）、无法被 IN 展开为常量列表时
- 需要关联字段为 NULL 安全（IN 对 NULL 敏感，NULL 值会导致整个条件为 UNKNOWN）
IN 更合适的情况
IN 在子查询返回结果集较小（一般建议
- 子查询是静态列表或轻量级查询（如 SELECT id FROM status WHERE type = 'active'）
- 子查询结果可完全缓存，且重复执行多次（某些数据库会对简单 IN 子查询做物化优化）
- 外层表极大、子查询极小，此时 IN 的哈希构建成本远低于 EXISTS 的逐行探查开销
- 使用的是主键或唯一索引字段，且无 NULL 值干扰
真实案例：用户订单状态同步慢
原 SQL 执行超 8 秒：
SELECT u.* FROM users u WHERE u.id IN (SELECT user_id FROM orders WHERE status = 'paid');
问题分析：orders 表超 500 万行，user_id 无索引，子查询全表扫描 + 外层 IN 转成临时哈希表，内存压力大。
优化后（改用 EXISTS + 补索引）：
SELECT u.* FROM users u WHERE EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id AND o.status = 'paid');
同时在 orders(user_id, status) 上创建联合索引。执行时间降至 0.12 秒。
关键点：EXISTS 让优化器走 Nested Loop + 索引查找；联合索引让每次探查仅需 2–3 次 B+ 树访问。
避坑提醒：别忽略执行计划与 NULL
用 EXPLAIN 或执行计划工具确认实际走索引，避免 EXISTS 内部未命中索引反而变慢。
- IN 子句中若子查询返回 NULL，整行会被过滤掉（SQL 标准行为），而 EXISTS 不受 NULL 影响
- MySQL 5.7+ 对简单 IN 自动重写为 semi-join，可能比手写 EXISTS 还快；但复杂子查询仍推荐 EXISTS
- PostgreSQL 中，IN 和 EXISTS 在多数场景性能接近，但 EXISTS 更易被正确推下谓词，利于分区裁剪
- Oracle 需注意 IN 的 1000 项限制，超限必须拆分或改用 EXISTS
