优先用in当子查询结果
选 EXISTS 还是 IN，不看表大小，只看子查询实际返回多少行、有没有索引、会不会遇到 NULL —— 这三点定生死。
子查询结果集小于 200 行时，优先用 IN
当子查询返回几十到一两百条记录（比如查状态码、部门 ID、枚举配置），IN 更稳：
-
IN只执行一次子查询，结果集小，内存占用低，后续主表走ref或range索引匹配快 - MySQL 5.6+ 会自动把
IN (subquery)改写成物化临时表 + 哈希查找，效率接近EXISTS - 注意：子查询里不能有
NULL，否则1 IN (1, NULL)返回UNKNOWN，整条记录被过滤 - 示例适用场景：
SELECT * FROM users WHERE status_id IN (SELECT id FROM sys_status WHERE type = 'active')（sys_status仅 12 条）
子查询结果集超过 5000 行，或不确定是否含 NULL，直接上 EXISTS
一旦子查询可能返回几千甚至几万行（比如“近 30 天下单用户”、“所有已审核商品 ID”），EXISTS 的短路机制立刻生效：
-
EXISTS不缓存结果集，每次只查内表是否存在匹配，找到第一条就停，避免全扫 - 只要内表关联字段有索引（如
orders.user_id），每次子查询都是点查，rows=1很常见 -
EXISTS完全无视NULL：即使user.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 的 type 和 rows
同一句 SQL 在不同实例上可能走完全不同路径，经验会骗人：
- 看
type：出现ALL或index就说明没走对索引，eq_ref/ref才是好信号 - 看
rows：如果EXISTS子查询的预估扫描行数是 1，说明命中了唯一索引；IN对应的rows如果远超子查询实际行数，大概率触发了全表扫描 - 注意
select_type：如果是DEPENDENT SUBQUERY，说明是相关子查询，每行都重执行——这是EXISTS的常态，但也是IN出现性能断崖的前兆 - 真实案例：某订单中心改写后，
IN平均 4.8 秒 →EXISTS0.9 秒，差异来自子查询返回 30 万product_id，且orders.product_id有索引
最常被忽略的其实是关联条件漏写和 NULL 陷阱——前者让 EXISTS 变成恒真，后者让 IN 悄悄丢数据。上线前不跑 EXPLAIN，等于裸奔。
