优先用EXISTS判断值是否在子查询结果中，用IN判断值是否在固定值列表中；IN处理动态子查询低效且对NULL不安全，EXISTS通过半连接和提前终止高效支持存在性判断。
直接说结论：判断“某个值是否在子查询结果中”时，优先用 EXISTS；判断“某个值是否在明确的固定值列表中”（如 IN (1, 2, 3)），必须用 IN —— 两者根本不是同一类问题，混用会出错或低效。
IN 适合查显式值列表，不适合查动态子查询结果集
当你写 WHERE id IN (101, 102, 105)，MySQL 直接走哈希查找或二分，极快；但一旦换成 WHERE id IN (SELECT user_id FROM orders WHERE status = 'paid')，就变成“先执行子查询、缓存全部结果、再逐行比对”，代价陡增。
- 子查询返回 10 万行？
IN就得在内存里建一个 10 万元素的集合，主表每行都去查一遍 - 子查询含
NULL？NOT IN会整个失效（返回空结果），这是线上事故高发点 - 即使加了索引，
IN子查询仍可能触发物化临时表，尤其在 MySQL 5.7 及更早版本
EXISTS 的本质是“半连接 + 提前终止”，天然适合存在性判断
EXISTS 不关心子查询返回什么，只看“能不能查到一行”。它对外层每一行执行一次带关联条件的子查询，命中即停 —— 这正是“判断是否存在”的最短路径。
- 例如
WHERE EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id AND o.amount > 100)，只要用户有一笔超 100 的订单，立刻返回TRUE，不扫其余订单 - 子查询能用上
o.user_id索引，外层u.id是否有索引影响不大（因为是驱动表） - 对
NULL安全：NOT EXISTS行为稳定，不会因子查询含NULL而静默失败
大数据量下 IN 和 EXISTS 的执行计划差异肉眼可见
用 EXPLAIN 看执行计划时，关键区别在 type 和 Extra 字段：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
-
IN子查询常见type: ALL（全表扫描子查询表）+Extra: Using where; Using temporary -
EXISTS通常显示type: ref或type: eq_ref（走了索引）+Extra: Using where; Using index - 当子查询含聚合（如
GROUP BY）或DISTINCT，IN几乎必物化，EXISTS仍可走索引下推
别被“小数据量差不多”骗了，上线后容易翻车
本地测 1 万行时 IN 和 EXISTS 耗时差 20ms，看起来无感；但生产环境订单表 500 万行，同样逻辑的 IN 查询可能从 8s 涨到 40s，而 EXISTS 仍稳定在 1.2s 左右 —— 因为它的执行路径不随子查询结果集大小线性增长。
真正容易被忽略的是：业务初期用 IN 写得顺手，等数据量上来、慢查询报警频发，再改 EXISTS 往往要连带调整子查询逻辑（比如补关联条件）、验证语义一致性，成本远高于一开始就写对。
