改写join后反而更慢，主因是中间结果集行数爆炸导致内存与排序压力陡增；in子查询在mysql 5.6+常被自动优化为semi-join，性能与join相当，关键取决于执行计划、索引生效及结果集大小。
子查询和 JOIN 没有绝对快慢之分，真正决定性能的是执行计划、索引是否生效、中间结果集大小，而不是你写了 IN 还是 JOIN。
为什么改写 JOIN 后反而更慢？
很多人把 SELECT u.name, (SELECT COUNT(*) FROM orders o WHERE o.user_id = u.id) 改成 LEFT JOIN orders ON u.id = o.user_id GROUP BY u.id，结果变慢——问题不在语法，而在行数爆炸。
- 一个用户有 500 笔订单，
LEFT JOIN后中间结果先膨胀 500 倍，再GROUP BY聚合，内存和排序压力陡增 -
INNER JOIN虽不膨胀，但会丢掉无订单用户；LEFT JOIN又得小心COUNT(*)把NULL也计进去，必须写成COUNT(o.id) - 如果只是判断“有没有订单”，
EXISTS比LEFT JOIN ... IS NOT NULL更轻量，找到第一个匹配就停，不生成中间行
MySQL 5.6+ 的 IN 子查询其实常被自动优化
只要子查询满足条件（无 GROUP BY、无 LIMIT、无 ORDER BY），MySQL 优化器大概率把它转成 semi-join，执行路径和 JOIN 几乎一样。
- 写
WHERE id IN (SELECT user_id FROM orders)和写INNER JOIN orders在 EXPLAIN 里可能看到相同的type: eq_ref或type: ref - 但如果子查询里有
SELECT DISTINCT user_id FROM orders GROUP BY user_id，优化器直接放弃重写，退化为逐行物化，性能断崖下跌 - 别迷信“IN 一定慢”，先看
EXPLAIN输出里的select_type：如果是DEPENDENT SUBQUERY，说明每行都执行一次，这才是真瓶颈
索引失效比写法选择更致命
无论你用子查询还是 JOIN，只要连接字段或过滤条件没走索引，性能差距毫无意义。
-
WHERE status IN ('active', 'pending')如果status列没索引，IN和JOIN都得全表扫描 - 复合索引顺序必须匹配查询模式：对
WHERE user_id = ? AND created_at > ?，索引必须是(user_id, created_at)，反过来就失效 -
EXISTS的内层查询依赖外层字段时，user_id字段必须有索引，否则变成嵌套循环 + 全表扫描
真正容易被忽略的点是：中间结果集大小。它不像索引那样能一眼看出，却在 EXPLAIN 的 rows 和 Extra 字段里藏着线索——比如出现 Using temporary 或 Using filesort，基本就是膨胀或排序失控了。
