EXISTS比IN更适合存在性判断，因其采用短路机制、不受NULL影响、易走索引且支持半连接优化；IN适用于固定小列表或子查询结果集小的场景，但遇NULL会返回UNKNOWN导致数据丢失。
嵌套子查询和JOIN没有绝对快慢，关键看执行计划是否能走索引、驱动表是否小、语义是否匹配。盲目换写法不解决问题，反而可能让优化器更难选对路径。
EXISTS比IN更适合存在性判断
当你只关心“有没有匹配行”，而不是“匹配了哪些值”，EXISTS 通常比 IN 更稳。优化器对 EXISTS 更容易做半连接（semi-join）优化，且能在找到第一行就终止内层扫描；而 IN 子查询若没走物化或哈希查找，可能先全量执行子查询再逐行比对。
-
IN在子查询结果固定且极小（如IN (1, 2, 3)）时可读性好，但若子查询返回 NULL，整个条件会变成 UNKNOWN，导致意外丢数据 -
EXISTS不受 NULL 影响，语义清晰，且SELECT 1写法让优化器明确知道只需探查，不取字段 - 如果内表有
(user_id, status)联合索引，EXISTS (SELECT 1 FROM orders WHERE user_id = u.id AND status = 'paid')能直接走索引，IN则可能因去重或 NULL 处理绕过索引
JOIN不是万能的，小结果集驱动大表易翻车
用 JOIN 关联时，MySQL 默认按统计信息选驱动表。但如果外层主表（比如 users）只有 100 行，而被关联的 orders 表有千万行，却硬写成 users JOIN orders，优化器可能仍选 orders 当驱动表——尤其当 orders 上缺失 user_id 索引时，就会触发全表扫描 + 嵌套循环，性能断崖下跌。
- 显式控制驱动顺序：用
STRAIGHT_JOIN强制users先扫，再对每行去orders查索引（前提是orders.user_id有索引） - 检查
EXPLAIN的type字段：要是出现ALL或index，说明驱动表选错了或缺索引 - 别忽略
rows预估：如果显示要扫描几十万行，哪怕key显示用了索引，实际也可能因回表或范围过大而慢
派生表（FROM 中的子查询）容易被物化，但未必慢
把子查询放在 FROM 子句里生成临时表（比如 SELECT * FROM (SELECT user_id, COUNT(*) c FROM orders GROUP BY user_id) t WHERE c > 5），MySQL 5.7+ 默认会尝试物化并加隐式索引，不一定比 JOIN 差。但要注意物化表无统计信息，优化器可能低估/高估行数，导致后续连接策略出错。
- 物化后无法利用原表索引，所以子查询里该加的索引（如
orders(user_id, created_at)）必须提前建好 - 如果子查询结果确定很小（WHERE 条件就会在内存临时表上全扫
-
MySQL 8.0+支持LATERAL派生表，允许子查询引用外层字段，这种场景下语义只能靠子查询表达，硬转JOIN反而难写对
真正决定快慢的是索引，不是写法本身
你花一小时改写 SQL，不如花五分钟看一眼 EXPLAIN 里的 key 和 Extra 字段。很多所谓“子查询慢”的问题，根子都在缺失联合索引或索引顺序不对。
- 对
JOIN：确保被驱动表的关联列上有索引，最好是覆盖索引（比如SELECT id, name FROM users JOIN orders ON users.id = orders.user_id，索引orders(user_id, id, name)能避免回表） - 对
EXISTS：内表的 WHERE 条件列要进联合索引，顺序按等值条件优先（user_id在前，status在后） - 别信“
SELECT *一定慢”——如果走了覆盖索引，SELECT *和SELECT id性能几乎一样；真慢是因为没索引，被迫回表或全表扫描
最常被忽略的一点：统计信息过期。ANALYZE TABLE 不是摆设，尤其在大批量导入或删除后，优化器基于错误的行数估算选错驱动表，怎么调写法都救不回来。
