相关子查询慢的本质是数据库为外层每行重复执行内层逻辑，应通过识别外层字段引用、执行计划中的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 扫描量和实际执行时间——差一个数量级，就说明还没打到根上。