exists 通常比 in 快，因其不物化子查询结果且支持短路退出；in 先生成临时结果集，数据量大时易内存暴涨或全表扫描；not in 存在 null 逻辑错误风险，not exists 则无此问题。
EXISTS 通常比 IN 快，但不是因为语法本身更高级，而是执行路径不同——它不建临时结果集，且能短路退出；而 IN 在子查询结果大、无索引或含 NULL 时，容易触发内存暴涨、全表扫描或逻辑错误。
IN 先物化子查询，EXISTS 是逐行驱动 + 短路判断
IN 的典型执行流程是：先完整跑完 SELECT id FROM orders WHERE status = 'shipped'，把所有匹配的 ID 塞进内存临时表，再拿主表每一行去查这个哈希表。如果子查询返回 50 万行，这个临时结构就得建起来，后续比对还可能退化成全量扫描。
EXISTS 则完全不同：EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id AND o.status = 'shipped') 中，每取主表 u 的一行，就用该行的 u.id 去 orders 表里走一次索引查找；只要命中第一条，立刻停，不继续扫。
- IN 的开销随子查询结果集大小线性增长
- EXISTS 的单次子查询成本固定（一次索引点查），总成本 ≈ 外表行数 × 单次点查耗时
- 若
orders(user_id)没索引，EXISTS 也会变慢，但至少不会爆内存
NOT IN 有空值陷阱，NOT EXISTS 没这个问题
只要子查询里任意一行的字段为 NULL，比如 SELECT user_id FROM logs WHERE type = 'error' 返回了 NULL，整个 NOT IN 条件就恒为 UNKNOWN，结果集为空——这不是慢，是错。
NOT EXISTS 完全不受影响，它只问“是否存在匹配”，NULL 不参与布尔判断。
- 写
WHERE id NOT IN (SELECT user_id FROM logs)前，必须确认logs.user_id是NOT NULL，否则结果不可信 - 即使当前没
NULL，未来加字段或改约束也可能埋雷 - MySQL 8.0+ 的
EXPLAIN FORMAT=TREE里，NOT EXISTS仍显示Using index，NOT IN往往是type: ALL
什么时候 IN 反而更快？别盲目替换
IN 并非过时语法，它在以下场景天然合适：
-
WHERE status IN ('active', 'pending', 'archived')—— 静态列表，根本没子查询，MySQL 内部直接哈希查 -
WHERE order_id IN (SELECT id FROM small_config)—— 子查询来自小表（ - 子查询结果要复用多次，比如后续还要
JOIN或聚合，先CREATE TEMPORARY TABLE存起来再用IN，比反复触发EXISTS更省 - MySQL 8.0+ 开启半连接优化，且优化器判定物化成本更低时，
IN和EXISTS的执行计划可能完全一致
真正该盯住的是执行计划，不是语法选择
同一语义的 SQL，EXPLAIN 出来的 rows、type、key 才是关键。比如：
-
EXISTS显示dependent subquery+Using where; Using index→ 内表索引生效，大概率快 -
IN显示materialized+key: NULL→ 外表没走索引，哪怕子查询只有 10 行也慢 - 两者都显示
semijoin→ MySQL 已重写为等价连接，性能差异趋近于零
最常被忽略的一点：外表索引对 EXISTS 基本无效，它的性能命脉压在内表关联字段是否有索引上；而 IN 的性能瓶颈往往在外表字段是否命中索引。
