相关子查询慢的本质是数据库为外层每行重复执行内层逻辑，应通过识别外层字段引用、执行计划中的DEPENDENT SUBQUERY/SubPlan及扫描行数远超结果行数等信号及时改写为JOIN、预聚合或窗口函数。
相关子查询慢，本质是数据库被迫为外层每一行重复执行内层逻辑——这不是写法问题，而是执行模型被拖垮了。 看到 EXPLAIN 里出现 DEPENDENT SUBQUERY 或 SubPlan，就该立刻停手改写，别等它跑出 8 秒再排查。
怎么一眼识别相关子查询正在拖慢查询
关键不是看语法有没有括号，而是看子查询里是否引用了外层表的字段。比如 WHERE o.amount > (SELECT AVG(o2.amount) FROM orders o2 WHERE o2.user_id = o.user_id)，末尾的 o.user_id 就是典型信号。
- 执行计划中出现
DEPENDENT SUBQUERY（MySQL）或SubPlan（PostgreSQL），且rows列远大于最终结果行数（比如扫描 200 万行，只返回 120 行） -
type是ALL或index，Extra含Using where; Using temporary; Using filesort - 子查询出现在
SELECT列表里（标量子查询），如(SELECT COUNT(*) FROM logs l WHERE l.order_id = o.id)，这种几乎必然触发嵌套循环
IN/EXISTS 子查询优先转成 JOIN，但要注意语义陷阱
WHERE 中的 IN 或 EXISTS 多数可安全转为 INNER JOIN，前提是业务允许主表因一对多关系而重复——比如查“有支付订单的用户”，IN 和 JOIN 结果一致；但若原意是“所有用户，标出是否有支付订单”，就必须用 LEFT JOIN + IS NOT NULL 判断，否则漏数据。
- 外层小、内层大且连接字段有索引 → 改用
EXISTS，避免构造大临时结果集 - 外层大、内层小且确定无
NULL→IN可能更快，现代优化器常自动转成哈希 semi-join - 绝对不要写
NOT IN (SELECT ...)：只要子查询结果含NULL，整条查询就返回空；换成NOT EXISTS或补IS NOT NULL条件
标量子查询必须预聚合，不能靠优化器自动消除
SELECT name, (SELECT AVG(score) FROM scores s2 WHERE s2.student_id = s1.id) FROM students s1 这类写法，哪怕 MySQL 8.0+ 或 SQL Server 2022+ 声称支持标量消除，也得看执行计划里是否真没了 Compute Scalar 节点。生产环境别赌这个。
- 先用 CTE 或派生表预聚合：
WITH student_avg AS (SELECT student_id, AVG(score) avg_s FROM scores GROUP BY student_id)，再LEFT JOIN回主表 - 能用窗口函数就不用子查询：
AVG(score) OVER (PARTITION BY student_id)，零额外扫描，语义清晰 - 如果子查询带复杂过滤（如
WHERE status = 'active'），确保scores(student_id, status)有复合索引，否则预聚合也白搭
达梦、金仓等国产库要特别注意驱动表顺序和索引覆盖
达梦优化器有时会错误选择大表作驱动表，导致嵌套循环连接极其低效；金仓 V009R002C014+ 虽支持标量子查询消除，但仅限无 GROUP BY、无 LIMIT 的简单场景。
- 显式用
/*+ USE_NL(table1, table2) */提示强制走索引嵌套循环（达梦/Oracle 风格） - 确保连接字段、子查询
WHERE字段、排序字段都在同一复合索引里，例如orders(customer_id, status, created_at) - 避免
SELECT *：JOIN 后字段越多，Join Buffer 压力越大，内存拷贝开销越明显
真正卡住性能的往往不是“子查询”这个语法，而是改写时忽略了数据分布、NULL 语义、一对多放大，以及索引没建在真正被驱动的路径上。每次改写后，必须用 EXPLAIN ANALYZE 对比 rows 扫描量和实际执行时间——差一个数量级，就说明还没打到根上。
