EXISTS 更稳、更可预期；IN 仅在子查询结果极小时有优势。
没有绝对更优，但绝大多数生产场景下 EXISTS 更稳、更可预期；IN 只在子查询结果极小（
EXISTS 为什么在多数生产环境里更可靠
生产库通常面临数据量波动大、索引覆盖不全、查询条件动态变化等问题。EXISTS 的“逐行驱动 + 短路”机制天然适配这类不确定性：
- 子查询只要命中一次索引查找就退出，
EXISTS不生成中间结果集，内存压力低，不易触发tmp_table_size溢出或 OOM - 即使子查询表增长到千万级，只要
WHERE条件字段有索引（如customer_id），单次查找仍稳定在毫秒级 - 完全无视
NULL—— 子查询里字段为NULL不影响布尔判断，不会静默返回空结果 - 执行计划中常显示为
semijoin或dependent subquery，配合Using index就基本能确认索引生效
IN 在什么情况下真能更快
IN 并非一无是处，但它胜出的条件非常具体，稍有偏差就反转：
- 子查询返回结果极少（例如
SELECT id FROM status_config WHERE active = 1返回 5 行），且已缓存或物化为常量列表 - 主表极大（百万+ 行），但关联字段（如
user_id）有高效索引，WHERE user_id IN (...)能走range或ref类型扫描 - 数据库版本较新（MySQL 8.0+ / PostgreSQL 12+），优化器将
IN自动重写为哈希半连接（Hash Semi Join） - 子查询本身不含
JOIN或复杂计算，否则物化开销陡增，IN反而变慢
最容易被忽略的致命坑：NOT IN 和索引错配
这两个问题在上线后才暴露，排查成本极高：
-
NOT IN遇到子查询任意一行含NULL（哪怕只有一条日志记录的user_id IS NULL），整个条件判为UNKNOWN，结果集直接为空——你查不到数据，EXPLAIN却看不出异常 -
EXISTS子查询漏写关联条件（如写成WHERE c.status = 'active'而非WHERE c.id = o.customer_id AND c.status = 'active'），会退化成无关联子查询，每次扫描全表，rows暴涨十倍以上 -
IN的子查询字段没索引，或主表关联字段没索引，type: ALL会悄无声息地拖垮整条 SQL，而EXISTS至少还能靠外层行数可控
真正该盯住的不是语法选哪个，而是 EXPLAIN 输出里的 type、rows、key 三列是否符合预期——尤其当数据量从测试库的 1 万涨到生产库的 200 万时，执行计划可能彻底改变。
