subplan或dependent subquery表明优化器未去关联化，正用嵌套循环执行相关子查询；需改写为join、窗口函数或启用semijoin/materialization优化。

EXPLAIN 里看到 SubPlan 就说明没解关联

数据库执行计划中出现 SubPlan（PostgreSQL）或 dependent subquery（MySQL），基本等于告诉你：优化器放弃了去关联化，正用嵌套循环硬扛。这不是“还没优化”，而是明确信号——它没把相关子查询转成 Semi-Join、Anti-Join 或物化临时表。

常见错误现象：EXPLAIN ANALYZE 显示外层扫描 10 万行，内层子查询被调用 10 万次，rows 列暴涨，Shared Hit Blocks 异常高；单独跑子查询毫秒级，嵌套后几十秒。

• 检查子查询是否引用了外层字段（如 WHERE o.user_id = u.id），有就是相关子查询，必须干预
• MySQL 5.7 默认关闭 semijoin，需手动开启：SET optimizer_switch='semijoin=on,materialization=on'
• PostgreSQL 12+ 对简单 EXISTS 和 IN 会自动 unnest，但带 GROUP BY、LIMIT 或窗口函数时大概率失效

标量子查询几乎必然走 Nested Loop

出现在 SELECT 列中的相关标量子查询（比如 (SELECT COUNT(*) FROM logs l WHERE l.user_id = u.id)），PostgreSQL 和 SQL Server 都无法转成 Hash 或 Merge Join，只能逐行调用。哪怕内层加了索引，也挡不住外层 N 次随机 I/O。

实操建议：

• 优先改写为 LEFT JOIN ... GROUP BY，注意加 DISTINCT 或聚合去重，避免因一对多放大主表行数
• 若必须保留标量语义（如只取最新一条），改用窗口函数：ROW_NUMBER() OVER (PARTITION BY u.id ORDER BY l.created_at DESC) + 外层过滤
• MySQL 用户慎用 @var 在子查询中传值——视图和 CTE 不支持会话变量，且无法下推条件

JOIN 改写前先验证语义等价性

把 WHERE id IN (SELECT user_id FROM orders) 直接改成 INNER JOIN orders ON users.id = orders.user_id 看似合理，但实际可能漏数据或重复：原意是“查用户”，JOIN 后变成“查有订单的用户”，且一个用户多笔订单会导致同一用户出现多次。

关键判断点：

• 原子查询在 WHERE 中作存在性检查（IN/EXISTS）→ 用 EXISTS 或 INNER JOIN，但需确认业务是否允许丢弃无匹配记录
• 原意是“补字段”（如查用户并附带订单数）→ 必须用 LEFT JOIN ... GROUP BY，不能用 IN 改写
• 含 NOT IN 且子查询列可能为 NULL → 直接失效，必须换 NOT EXISTS 或补 IS NOT NULL

CTE 和物化提示比视图更可控

想把深层嵌套拆开，别急着建视图。MySQL 5.7 前不支持视图合并，哪怕你只查视图中一个字段，也会全量计算整个子查询；而 CTE 在 PostgreSQL/SQL Server 中可被优化器下推过滤条件，MySQL 8.0+ 的 WITH 也支持 MATERIALIZED 提示强制物化。

使用场景对比：

• 子查询只用一次、带参数（如日期范围）→ 用 CTE，写法轻、权限干净、条件易下推
• 多个查询共用同一逻辑（如报表中反复算用户复购率）→ 视图更合适，但必须显式处理列名冲突、NULL 传播、调用者权限
• 确定某层子查询结果集小且稳定 → 加 /*+ MATERIALIZE */（Oracle）或 /*+ USE_HASH(u o) */（指定连接算法）比依赖优化器更可靠

真正难的不是“怎么写 JOIN”，而是搞清哪一层的 NULL、重复、空关联会让结果语义偏移——这些细节在执行计划里根本看不到，只能靠人工比对数据。