EXISTS对外层表逐行执行子查询，找到即停；IN先执行子查询缓存结果再比对。EXISTS不受NULL影响，IN遇NULL返回UNKNOWN；NOT IN含NULL时结果为空，应改用NOT EXISTS；性能取决于表大小与索引，需以EXPLAIN为准。
EXISTS 和 IN 的执行逻辑完全不同
EXISTS 是对外层表逐行扫描，每行都执行一次子查询，只要子查询返回至少一行就返回 TRUE，找到即停；IN 是先完整执行子查询，把结果集缓存为一个值列表（比如 (1,2,3,NULL)），再用外层字段逐一比对。
这意味着：
- EXISTS 不关心子查询返回什么，SELECT 1、SELECT * 效果一样
- IN 必须确保子查询只返回单列，且不能有语法错误或类型不匹配
- 如果子查询结果为空，EXISTS 返回 FALSE，IN 返回空结果集（逻辑上等价于 FALSE）
NULL 值会让 IN 出现意外结果
当子查询返回的值中包含 NULL，比如 SELECT id FROM order WHERE user_id IS NULL，那么 id IN (1,2,NULL) 整体判断结果为 UNKNOWN，该行会被过滤掉——即使外层 id 确实等于 1 或 2。
这是 SQL 三值逻辑导致的，而 EXISTS 完全不受 NULL 影响，因为它只看“有没有行”，不比较值。
常见踩坑点：
- 用 NOT IN 查“不在某列表中的用户”时，只要子查询里有任意一个 NULL，整个结果就是空
- 此时必须改用 NOT EXISTS，否则查不到任何数据
索引使用和性能取决于驱动顺序
数据库优化器会根据表大小、索引分布和统计信息决定走哪条路径，但你可以通过写法引导它：
- 如果外层表小、子查询表大（比如查几个特定用户有没有订单），优先用
EXISTS，它能利用子查询表上的索引（如order(user_id)） - 如果外层表大、子查询结果很小（比如查所有用户是否属于预定义的 5 个 VIP ID），优先用
IN，避免对外层表每行都触发一次子查询 -
IN在子查询是固定值列表时（IN (1,2,3)）效率极高，数据库会直接走哈希查找 -
EXISTS在子查询带关联条件（WHERE order.user_id = user.id）时才能体现优势，非关联写法（EXISTS (SELECT 1 FROM order)）可能变成常量判断，甚至被优化掉
别直接套“EXISTS 一定比 IN 快”的经验
实际执行计划才是唯一标准。同一句 SQL 在不同数据分布下可能走完全不同路径：
例如：
- 表 user 有 10 万行，order 有 100 行 → IN 更快
- 表 user 有 100 行，order 有 1000 万行 → EXISTS 更快
- 两张表都有几万行，且关联字段都有索引 → JOIN 往往比两者都快，应优先考虑
真正容易被忽略的是：写完语句后一定要看 EXPLAIN 输出，确认是否命中索引、是否用了预期的驱动表，而不是凭印象切换写法。
