EXISTS 和 IN 在什么情况下性能差异最明显
当子查询返回大量数据，而外层表较小时，
IN容易因隐式去重和临时表膨胀变慢；相反，
EXISTS只需找到一条匹配就短路退出，对大结果集更友好。但反过来，如果子查询结果极少（比如只返回几行），且已建好索引，
IN可能更快——因为优化器能走
range或
const访问类型，而
EXISTS仍要为每行外层数据执行一次相关子查询。
关键看驱动表和被驱动表的大小、索引覆盖程度、是否允许 NULL 值参与比较。
NULL 值会让 IN 返回意外结果
IN对
NULL敏感：只要子查询中任意一行是
NULL，整个表达式可能变成
UNKNOWN，导致 WHERE 条件不成立（即该行被过滤掉）。而
EXISTS不受
NULL影响，它只判断是否存在满足条件的行，与字段值是否为
NULL无关。 如果子查询含
SELECT col FROM t2 WHERE ...，且
col允许为
NULL，
IN行为不可靠 修复方式不是加
IS NOT NULL，而是改用
EXISTS或确保子查询显式过滤
NULL常见误写：
WHERE id IN (SELECT user_id FROM logs)—— 若
user_id有
NULL，这部分逻辑就失效
等价改写时要注意相关子查询的语义
把
IN改成
EXISTS不是简单替换，必须检查子查询是否引用了外层表字段。否则会从非相关子查询变成相关子查询，或反之，导致结果不一致。
SELECT * FROM users u WHERE u.id IN (SELECT user_id FROM orders o WHERE o.status = 'paid');
这等价于：
SELECT * FROM users u WHERE EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id AND o.status = 'paid');
注意两点：
EXISTS子查询里必须有
o.user_id = u.id这类关联条件，否则变成“只要 orders 表里存在任意一条 paid 订单就返回所有用户”
SELECT 1是惯用写法，比
SELECT *更轻量，MySQL 会忽略实际列名 若原
IN子查询不含外层引用（即独立子查询），强行改成
EXISTS会导致逻辑错误
用 EXPLAIN 验证执行计划比背规则更可靠
MySQL 版本、统计信息、索引策略都会影响优化器选择。同一语句在 5.7 和 8.0 中可能走完全不同路径。别依赖“EXISTS 一定比 IN 快”这种经验，而要看
EXPLAIN输出的
type、
rows、
Extra字段。 关注
type是否为
eq_ref或
ref；如果是
ALL或
index，说明没走索引
Extra: Using where; Using index是理想状态；
Using temporary; Using filesort是危险信号 对
IN子查询，注意
select_type是
DEPENDENT SUBQUERY还是
PRIMARY，前者意味着每次外层行都要执行一次子查询
真正容易被忽略的是：即使写了
EXISTS，如果关联字段没索引，它依然会全表扫描内表；而一个带索引的
IN列表（如
IN (1,2,3)）反而可能走
range索引扫描。优化不能脱离数据分布和索引设计谈语法。
