MySQL中IN子查询优先转为半连接优化（如FirstMatch），但遇ORDER BY、LIMIT或相关子查询则退化为逐行执行；EXISTS天然支持短路且对NULL不敏感，性能更稳定；ANY与IN在=场景等价，但>ANY等价于>MIN()；效率看EXPLAIN是否物化、走索引及rows值。
MySQL 中 IN 子查询到底是怎么执行的
MySQL 对 IN 子查询的处理方式取决于子查询是否相关（correlated）、结果集大小、是否有索引，以及 MySQL 版本（5.6/5.7/8.0 差异明显）。5.7+ 默认会尝试将非相关 IN 转为半连接（semi-join），用 FirstMatch 或 LooseScan 策略优化，避免对主表每行都重复执行子查询。
但一旦子查询里用了 ORDER BY、LIMIT、或引用了外部表字段（即变成相关子查询），优化器就会退回到「对主表每一行，执行一次子查询」的老路——性能断崖式下跌。
- 如果子查询返回空结果，
IN整体为FALSE（注意：NULL会导致整个表达式为UNKNOWN） -
IN后面的列表或子查询结果中只要有一个NULL，且主查询值不匹配任何非NULL项，则结果是UNKNOWN，不是FALSE，这在WHERE条件中会被当作不满足而过滤掉 - 子查询若无索引，又返回大量行，
IN可能触发临时表 + 文件排序，EXPLAIN中看到Using temporary; Using filesort
EXISTS 的执行逻辑和关键特性
EXISTS 是纯粹的「存在性检查」，不关心子查询返回什么列、多少行，只看是否至少有一行。优化器几乎总是将其转为半连接（即使没开 semi_join 开关），且天然支持短路：找到第一行就退出，不继续扫描。
它天然适合相关子查询场景，因为语法结构强制关联（比如 WHERE EXISTS (SELECT 1 FROM t2 WHERE t2.id = t1.ref_id)），而优化器能利用 t2.ref_id 上的索引快速定位。
-
EXISTS对NULL不敏感——子查询里哪怕只有SELECT NULL，只要有行返回，结果就是TRUE - 写成
NOT EXISTS时，无法利用大多数半连接优化，可能回退到嵌套循环，需特别留意执行计划 - 子查询中加
SELECT 1或SELECT *对性能无实质影响，MySQL 会忽略 SELECT 列表内容
ANY（含 = ANY）和 IN 的等价性与陷阱
col = ANY (subquery) 在语义和执行上基本等价于 col IN (subquery)，优化器通常做相同处理。但二者在 NULL 处理上完全一致：只要子查询结果含 NULL，且没有匹配项，整个表达式就是 UNKNOWN。
真正容易出问题的是 > ANY、 这类形式——它们不等价于 IN，而是等价于「比子查询结果中最小/最大值满足条件」。例如：salary > ANY (SELECT salary FROM manager) 意思是「工资高于任一经理的工资」，即「高于最低经理工资」。
-
> ANY等价于> MIN(...)；等价于 -
= ANY和IN在单列、非 NULL 场景下可互换，但IN更通用、可读性更好，建议优先用IN - 如果子查询返回空集，
= ANY返回FALSE；但> ANY返回FALSE（因无最小值可比较），这点常被忽略
怎么一眼看出执行效率高不高
别猜，直接看 EXPLAIN FORMAT=TREE（MySQL 8.0）或 EXPLAIN 的 type 和 Extra 字段。核心盯三点：
- 是否出现
materialized（物化子查询）——说明子查询被缓存为临时表，后续用哈希查找，通常是好事 -
Extra里有没有Using join buffer (Block Nested Loop)或Using where; Using index——前者危险，后者健康 - 子查询部分的
rows值是否远小于主表rows，且有key显示走了索引
EXPLAIN SELECT * FROM user u WHERE u.id IN (SELECT user_id FROM order WHERE status = 'paid');
如果 order(user_id, status) 有联合索引，这条大概率走 range + 物化；如果没有索引，order 表可能全表扫描，rows 显示几十万，那就得立刻加索引。
最常被忽略的一点：相关子查询里，外层字段没走索引，或者子查询里写了 SELECT * 却没用到所有列——这不会报错，但会让优化器放弃某些优化路径，老老实实嵌套循环。
