IN先物化子查询结果再哈希查找，EXISTS对外层每行执行一次子查询并可索引早停；IN对NULL敏感易返回UNKNOWN，EXISTS不受NULL影响；相关子查询优先用EXISTS，非相关且结果集小时可用IN。
IN 和 EXISTS 的执行逻辑差异
MySQL 里 IN 和 EXISTS 都能实现“某值是否存在于子查询结果中”的语义，但底层执行方式完全不同：IN 本质是把子查询结果物化成一个集合（临时表或哈希表），再做哈希查找；而 EXISTS 是对外层每一行执行一次子查询，只要子查询返回至少一行就为 TRUE，且通常可利用索引提前终止。
这意味着：当子查询结果集小、外层表大时，IN 更快；当子查询能高效走索引、且外层表小或中间结果早停时，EXISTS 更有优势。
NULL 值会让 IN 返回空结果
IN 对 NULL 敏感——只要子查询结果中包含 NULL，整个表达式可能意外返回空集或不符合预期的布尔值。例如：
SELECT * FROM orders WHERE customer_id IN (SELECT id FROM customers WHERE status = 'active');
如果 customers.id 允许为 NULL，且恰好有 status = 'active' 的记录其 id 为 NULL，那么该 IN 表达式对任何 customer_id 都不会匹配（因为 123 IN (1, 2, NULL) 的结果是 UNKNOWN，不满足 WHERE 条件）。
-
EXISTS不受子查询中NULL影响，它只关心是否存在行，不比较值 - 若子查询含
SELECT *或明确列，且关联字段允许NULL，务必检查是否加了IS NOT NULL过滤 - 用
IN时，建议显式排除NULL：SELECT id FROM customers WHERE status = 'active' AND id IS NOT NULL
相关子查询下 EXISTS 更易走索引
当子查询引用外层表字段（即相关子查询）时，EXISTS 更容易命中索引。例如：
SELECT * FROM users u WHERE EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id AND o.status = 'paid');
只要 orders(user_id, status) 有联合索引，MySQL 就能对每个 u.id 快速定位并判断是否存在匹配行。
而等价的 IN 写法会更难优化：
SELECT * FROM users u WHERE u.id IN (SELECT user_id FROM orders WHERE status = 'paid');
这里子查询不依赖 u，MySQL 可能先执行一次全量子查询，再对每个 u.id 做哈希查找——但如果 orders 很大，又没覆盖索引，性能反而下降。
- 相关子查询（带外层字段引用）优先选
EXISTS - 非相关子查询（子查询独立）且结果集较小（比如几十到几百行），
IN更直观也更稳 - 注意
IN列表长度限制：max_allowed_packet和optimizer_search_depth都可能影响超长IN列表的执行计划
EXISTS 的 SELECT 列完全无关紧要
EXISTS 只检测子查询是否返回行，子查询里的 SELECT 列内容被完全忽略。下面三者执行效果一致：
SELECT * FROM users WHERE EXISTS (SELECT 1 FROM orders WHERE user_id = users.id); SELECT * FROM users WHERE EXISTS (SELECT user_id FROM orders WHERE user_id = users.id); SELECT * FROM users WHERE EXISTS (SELECT * FROM orders WHERE user_id = users.id);
推荐写 SELECT 1，语义清晰且避免误触大字段或计算列带来的额外开销。
反过来说，如果子查询里写了 SELECT COUNT(*) 或聚合函数，不仅没意义，还强制 MySQL 扫全表/全索引，严重拖慢速度。
实际开发中容易忽略的一点：某些 ORM 框架生成的 EXISTS 子查询默认带 SELECT *，需确认是否可配置为 SELECT 1。
