in和exists性能无绝对优劣，取决于驱动表大小、子查询结果集大小及索引生效情况：in适合子查询结果集小、主表大且关联字段有索引的场景；exists适合主表小、子查询表大且内表关联字段有索引的场景；not in存在null逻辑陷阱，必须用not exists替代；最终应以explain执行计划中的type、rows、extra三列为准判断实际效率。
IN 和 EXISTS 没有绝对的“谁更高”，实际快慢取决于驱动表大小、子查询结果集大小、索引是否生效——不是语法本身的问题，而是执行计划是否选对了路。
什么时候IN更快？
IN 在子查询结果集小、主表大且关联字段有索引时往往更优。
它先执行子查询，把几十或几百个值加载进内存（比如 SELECT id FROM status_config WHERE active = 1），再用哈希查找或索引范围扫描匹配主表。
常见场景包括：
- 子查询是轻量配置表、枚举视图或带强过滤条件的小结果集
- 主表 WHERE id IN (...) 能走 id 索引，避免全表扫描
- MySQL 8.0+ 对这类 IN 子查询做了物化优化，生成临时哈希表，效率接近 EXISTS容易踩的坑：
- 把大表子查询硬塞进
IN，例如WHERE order_id IN (SELECT order_id FROM huge_log_table WHERE ...)→ 内存暴涨、主表被迫全扫 - 子查询字段没索引，导致先全表扫子表再拼集合，
IN失去意义
什么时候EXISTS更快？
EXISTS 在主表小、子查询表大、且子查询关联字段有索引时通常胜出。
它以主表为驱动，逐行调用子查询，只要找到第一条匹配就退出（半连接），不构造中间结果集。
典型例子：
- 主表 2 万订单，查“客户是否活跃”：WHERE EXISTS (SELECT 1 FROM customers c WHERE c.id = o.customer_id AND c.status = 'active')
- 子查询中 c.id 有索引，每次只需一次索引查找，总开销 ≈ 2 万 × 单次索引定位
关键限制：
- 子查询里漏写关联条件（如
WHERE c.id = o.customer_id），变成无关联子查询 → 每次都扫全表，比IN还慢 - 关联字段没索引，
EXISTS退化成嵌套循环全表扫描，type显示ALL，rows高得离谱
NOT IN 必须换成 NOT EXISTS
这不是性能问题，是逻辑陷阱。
NOT IN 遇到子查询返回任意 NULL（哪怕只有一行），整个表达式判为 UNKNOWN，结果集直接为空——你查不到数据，却看不出错在哪。
NOT EXISTS 完全不受 NULL 影响，语义稳定，且子查询仍可走索引。
即使你确认子表字段 NOT NULL，也建议统一用 NOT EXISTS：未来加空值后不会静默失效，执行计划也更可预期。
真正该盯住的不是写法，是 EXPLAIN
别猜，直接看执行计划。重点关注三列：
- type：出现 ref 或 range 才算走了索引；DEPENDENT SUBQUERY 表示没被优化，大概率慢
- rows：预估扫描行数，越接近实际匹配数越好
- Extra：含 Using index 是理想状态；Using join buffer 往往意味着没走索引
复杂点在于：MySQL 5.6+ 会自动把部分无关子查询 IN 改写成半连接，但只要子查询引用外层字段（相关子查询），就无法触发该优化——这时 EXISTS 反而更“诚实”，更容易被索引驱动。
