EXISTS 不一定比 IN 更高效，其优势依赖驱动表小、内层索引有效及优化器成功转换为半连接；IN 在主表大、子查询结果小且索引到位时反而更快；NOT IN 存在 NULL 逻辑陷阱，应统一用 NOT EXISTS。
EXISTS 不一定比 IN 更高效，但当你看到它更快时，通常是因为驱动表小、内层索引有效、且优化器成功走了半连接（semi-join）——而不是语法本身“更高级”。
EXISTS 为什么有时快：执行计划里藏着半连接
MySQL 5.6+ 默认尝试把符合条件的 EXISTS 重写为半连接，执行计划中会出现 Using semi-join 或 Semi-join (duplicate removal)。这意味着：不取值、不回表、不构造中间结果集，只确认“是否存在”。
而等价的 IN 子查询，即使逻辑相同，也可能被优化器判为需物化（Materialize），尤其当子查询含 GROUP BY、ORDER BY 或字段无索引时。
验证方式很简单：EXPLAIN FORMAT=TREE 对比两者的输出结构，别只看 rows。
IN 什么时候反而更快：主表大 + 子查询结果极小 + 索引到位
当子查询返回几十或几百个值（比如 SELECT id FROM config WHERE type = 'active'），且主表的关联字段有索引（如 WHERE order_id IN (...) 能走 order_id 索引），IN 往往更优：
• MySQL 8.0+ 会对这类子查询做物化哈希优化，匹配效率接近哈希查找
• 主表扫描一次即可完成全部匹配，避免逐行发起子查询带来的网络/解析开销
• 常见翻车点：把大表子查询硬塞进 IN，例如 WHERE id IN (SELECT id FROM huge_log_table WHERE ...) → 内存暴涨、全表扫主表、甚至 OOM
EXISTS 容易失效的三个硬条件
EXISTS 写了≠一定快。以下任一不满足，它就退化成嵌套循环全表扫描：
• 子查询里漏写关联条件，例如 EXISTS (SELECT 1 FROM customers WHERE status = 'active') → 变成无关联子查询，每次查全表
• 关联字段没索引，type 显示 ALL，rows 高得离谱
• SELECT 列不是常量，比如写成 SELECT customer_id 而非 SELECT 1，某些版本会误判需回表取值
NOT IN 必须换 NOT EXISTS：这不是性能问题，是逻辑陷阱
NOT IN 遇到子查询任意一行含 NULL（哪怕只有一条），整个条件恒为 UNKNOWN，结果集直接为空——你查不到数据，日志里也看不出错。NOT EXISTS 完全不受 NULL 影响，语义稳定，且仍可走索引。
即使你确认子表字段 NOT NULL，也建议统一用 NOT EXISTS：未来加空值后不会静默失效，执行计划也更可预期。
真正影响快慢的，从来不是 IN 或 EXISTS 这两个词，而是优化器有没有选对驱动表、索引是否被命中、以及 EXPLAIN 里 type、rows、Extra 三列暴露的真实路径。别猜，先看执行计划。
