执行效率取决于实际执行路径而非语法写法；应关注explain中的select_type和extra字段，如dependent subquery、using temporary、type与key等关键指标。
看执行计划，别猜写法
执行效率高不高，不取决于你写了 JOIN 还是写了 IN 或 EXISTS，而取决于数据库实际走的路径。MySQL 5.6+、PostgreSQL、SQL Server 都会把等价的 IN 子查询自动重写为 semi-join，执行计划里甚至看不到“子查询”字样。真正要盯的是 EXPLAIN 输出里的 select_type 和 Extra 字段：
- 出现
DEPENDENT SUBQUERY：外层每行都重跑一次内层，10 万用户 × 每次查订单表 = 至少 10 万次全表扫描（除非有索引） - 出现
Using temporary或Using filesort：说明中间结果集太大，被迫落盘或排序，这是比写法更致命的瓶颈 -
type是eq_ref或ref，且key列显示用了索引：无论写法如何，这条路基本是快的
主键/唯一字段关联优先用 EXISTS
判断“是否存在”这类逻辑，EXISTS 天然适合短路——找到第一条匹配就停，不构造完整结果集。尤其当外表小、内表大，且内表在关联字段上有索引时，它比 JOIN + DISTINCT 更轻量：
- 写法：
SELECT * FROM users u WHERE EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id AND o.status = 'paid') - 关键点：
orders(user_id, status)必须有复合索引，否则EXISTS就退化成嵌套循环 - 别用
IN替代：如果子查询返回NULL，IN整个条件变UNKNOWN，结果可能为空——EXISTS没这问题
多对一聚合场景，标量子查询反而更稳
比如查每个用户的最新订单时间：SELECT u.id, u.name, (SELECT MAX(o.created_at) FROM orders o WHERE o.user_id = u.id)。这种写法看似“慢”，但实际可能比 LEFT JOIN orders GROUP BY 更优：
- 不会导致行数爆炸：一个用户有 500 笔订单，
JOIN后先膨胀 500 倍再GROUP BY，内存和排序压力陡增 - 依赖索引高效定位：
orders(user_id, created_at)有复合索引时，每个标量子查询走索引 MIN/MAX 查找，O(log n) - 风险点：如果没索引，或子查询里加了
LIMIT/ORDER BY又没GROUP BY，MySQL 可能强制物化到磁盘临时表
改写 JOIN 后变慢？先检查中间结果集
很多人把 WHERE id IN (SELECT user_id FROM orders) 改成 INNER JOIN orders，结果更慢——不是 JOIN 有问题，而是中间结果集失控了：
-
INNER JOIN返回所有匹配行，一个用户有 10 笔订单，就生成 10 行；后续再DISTINCT或GROUP BY，代价远高于原IN的 semi-join 路径 -
LEFT JOIN更危险：若右表无匹配，仍保留左表行，但中间结果已按左表行数 × 平均匹配数膨胀，EXPLAIN的rows值会明显跳升 - 真正该动的不是语法，而是加索引、加过滤条件、或拆成两步查（比如先查出
user_id列表，再用IN批量查主表）
最常被忽略的不是“用哪个语法”，而是中间结果集大小——它不显眼，却直接决定是否落盘、是否排序、是否 OOM。每次调优前，先跑一遍 EXPLAIN (ANALYZE)，盯着 rows 和 Actual Total Time 看，比争论写法有用得多。
