DEPENDENT SUBQUERY是性能杀手，因外层每行都重复执行子查询，如users表10万行则logs扫描10万次；需通过EXPLAIN关注type和rows，优先优化索引与执行计划。
EXPLAIN 里看到 DEPENDENT SUBQUERY 就该警觉
这代表子查询每行都执行一次，是性能杀手。比如 SELECT name FROM users WHERE id = (SELECT user_id FROM logs WHERE user_id = users.id ORDER BY ts DESC LIMIT 1)，users 表有 10 万行，logs 表就得扫描 10 万次——哪怕加了索引，也扛不住。
真正要盯的是执行计划里的 type 和 rows：如果 type 是 ALL 或 index，且 rows 远大于最终结果行数，基本就是相关子查询在反复扫表。
- 用
EXISTS替代等值标量子查询，能提前终止；但别写成SELECT * FROM t1 WHERE EXISTS (SELECT 1 FROM t2 WHERE t2.id = t1.id AND t2.status = 'done')却忘了给t2.id和t2.status建复合索引 -
IN子查询在 MySQL 5.6+ 多数会被自动转成semi-join，但前提是子查询里不能有GROUP BY、ORDER BY或LIMIT，否则优化器直接放弃重写 - PostgreSQL 对相关子查询的物化支持更激进，但若子查询返回上万行，仍会触发磁盘临时表——看
EXPLAIN ANALYZE里的Temp File记录
JOIN 后 GROUP BY 或 DISTINCT 导致行数爆炸
很多人改写子查询为 JOIN 后反而更慢，问题常出在这儿：SELECT u.name, (SELECT COUNT(*) FROM orders o WHERE o.user_id = u.id) FROM users u 改成 SELECT u.name, COUNT(o.id) FROM users u LEFT JOIN orders o ON u.id = o.user_id GROUP BY u.id 看似合理，但若一个用户有 500 笔订单，中间结果集就先膨胀 500 倍，再聚合——内存和排序压力陡增。
这时候不如保留子查询，或改用窗口函数：SELECT u.name, COUNT(*) OVER (PARTITION BY u.id)（需 PostgreSQL 11+/MySQL 8.0+）。
- LEFT JOIN + COUNT() 必须配
GROUP BY，否则语法错误；而子查询天然隔离计算边界 - INNER JOIN 不会放大行数，但会丢掉无订单用户；用 LEFT JOIN 又得防 NULL，
COUNT(o.id)比COUNT(*)安全 - 如果只是判断“有没有订单”，
EXISTS比LEFT JOIN ... IS NOT NULL更轻量，不生成中间行
索引失效比写法选择更致命
无论你写子查询还是 JOIN，只要连接字段或 WHERE 条件没走索引，性能差距就毫无意义。比如 WHERE status IN ('active', 'pending')，如果 status 列没索引，IN 子查询和 JOIN 都得全表扫描。
复合索引顺序决定一切：对 SELECT * FROM orders WHERE user_id = ? AND created_at > ?，索引必须是 (user_id, created_at)，反过来就没用。
- 子查询中
SELECT id FROM t2 WHERE a = ? AND b = ?，索引(a, b)能用，(b, a)不能用 - JOIN 的
ON t1.x = t2.y，两边字段最好都有索引；若只有一边有，驱动表选错会导致嵌套循环变慢 - MySQL 8.0+ 的
EXPLAIN FORMAT=TREE会直接标出“Using index condition”，比老版Extra字段更直观
别信“子查询慢”或“JOIN 快”的笼统结论
现代数据库（MySQL 8.0+、PostgreSQL 12+、SQL Server 2019+）对等价逻辑的重写能力很强。同一个需求，IN 子查询和 INNER JOIN 经常生成一模一样的执行计划——区别只在语义是否清晰、维护是否方便。
真正卡住性能的，往往是那些被忽略的细节：统计信息陈旧导致优化器误判、TEXT/BLOB 字段拖慢临时表、JOIN 顺序被强制指定（STRAIGHT_JOIN）却没验证效果、或者开发环境用 100 行测试数据得出的“子查询更快”结论，在生产百万级数据上完全反转。
最该花时间的地方，不是纠结语法，而是跑一次 EXPLAIN ANALYZE（PostgreSQL）或 EXPLAIN FORMAT=TREE（MySQL），盯着实际 Actual Rows 和 Buffers 看——数字不会骗人。
