exists 和 in 性能差异最明显于子查询结果集大小与外层表相对关系不同：大结果集时 exists 短路优势显著，小结果集且索引良好时 in 可能更快；null 值使 in 行为不可靠而 exists 不受影响；改写需确保关联条件正确；执行计划（explain）比经验更可靠。
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 索引扫描。优化不能脱离数据分布和索引设计谈语法。
