结论：优先用in当子查询返回少于200行、无null且有索引；否则切exists并严格补全关联条件，同时用explain验证执行计划。
直接说结论：别看表大小，盯紧子查询实际返回多少行、有没有索引、会不会出NULL——这三点一齐满足，才敢用IN；只要有一条不稳，就切EXISTS，并立刻补上关联条件。
子查询返回少于200行且无NULL，优先用IN
比如查固定状态码、部门ID、配置项这类枚举型数据，子查询结果稳定在几十到一两百条，IN更轻量：
-
IN只执行一次子查询，结果集小，内存开销低，后续主表走ref或range索引快 - MySQL 5.6+ 会自动把
IN (subquery)物化成临时哈希表，匹配是O(1)查找 - 但必须确保子查询不含
NULL：否则1 IN (1, NULL)返回UNKNOWN，整行被过滤掉，悄无声息丢数据 - 示例：
SELECT * FROM users WHERE status_id IN (SELECT id FROM sys_status WHERE type = 'active')（sys_status仅12条，且id非空）
子查询可能返回超5000行或含NULL，必须用EXISTS
一旦子查询涉及“近30天用户”“所有已审核商品”这类动态大集合，EXISTS的短路机制立刻生效：
-
EXISTS不缓存结果集，每次只查内表是否存在匹配，找到第一条就停，避免全扫 - 只要内表关联字段有索引（如
orders.user_id），每次子查询都是点查，rows=1很常见 -
EXISTS完全无视NULL：即使users.id为NULL，子查询仍正常执行，只看WHERE是否成立 - 致命陷阱：漏写关联条件 →
WHERE EXISTS (SELECT 1 FROM orders WHERE status = 'paid')变成恒真，查出所有用户 - 正确写法必须带外层引用：
WHERE EXISTS (SELECT 1 FROM orders WHERE user_id = users.id AND status = 'paid')
上线前不跑EXPLAIN，等于裸奔
同一句SQL在不同实例上可能走完全不同执行路径，经验会骗人：
- 看
type：出现ALL或index说明没走对索引；eq_ref/ref才是好信号 - 看
rows：EXISTS子查询预估扫描行数要是1，说明命中了唯一索引；IN对应的rows如果远超子查询实际行数，大概率触发了全表扫描 - 看
select_type：如果是DEPENDENT SUBQUERY，说明是相关子查询，每行都重执行——这是EXISTS的常态，但也是IN性能断崖的前兆 - 特别注意
MATERIALIZED：表示子查询被物化，若物化表太大（比如几万行），I/O和内存压力会陡增
最常被忽略的其实是关联条件漏写和NULL陷阱——前者让EXISTS变成恒真，后者让IN悄悄丢数据。改完别急着上线，EXPLAIN跑一遍，确认type和rows符合预期再说。
