标量子查询不能替代JOIN，因其本质是逐行调用，易引发N+1查询，而JOIN是批量关联；仅在单值过滤且能被物化时才安全高效。

JOIN 不是“昂贵”的操作，多层标量子查询反而更容易变慢、出错、难维护。标量子查询（返回单行单列）只适合极少数场景——比如外层每行只需从另一张表取一个聚合值做判断，且该子查询能被数据库有效物化或优化。

标量子查询真能替代 JOIN 吗？

• 不能。标量子查询本质是「逐行调用」，而 JOIN 是「批量关联」。当你要拼接字段（如用户姓名、订单状态、商品类目），标量子查询会触发 N+1 查询模式：外层查 10 万行，子查询就执行 10 万次。
• MySQL 5.7 以前对相关标量子查询几乎不优化，执行计划里频繁出现 DEPENDENT SUBQUERY；即使在 MySQL 8.0 或 PostgreSQL 中，它也难以利用复合索引的覆盖能力。
• 如果你试图写三层嵌套标量子查询（例如 SELECT ..., (SELECT ... (SELECT ...))），优化器大概率放弃推导，退化为临时表 + 文件排序，性能比等价 JOIN 差 5–8 倍。

什么情况下标量子查询反而更安全？

• 只需单值过滤或计算，且逻辑明确依赖外层当前行：
  • 查“薪资高于本部门平均值的员工” → 可用标量子查询，但前提是子查询有 WHERE e2.dept_id = e1.dept_id 关联，且 dept_id 有索引
  • 统计“每个订单的客户等级”（等级由客户总消费决定）→ 若等级表很小、更新不频繁，标量子查询比 JOIN + GROUP BY 更易读，但必须加 LIMIT 1 防止多行报错
• 子查询结果为空时语义可控：AVG() 返回 NULL，比较 > NULL 结果为 UNKNOWN，该行自然被过滤——这符合三值逻辑，但容易被误认为“没数据”而非“条件不成立”

多层标量子查询的典型陷阱

• 字段名冲突：内层子查询若引用了和外层同名的列（如都叫 id），不加表别名会报错或取错值
• NULL 传播失控：一层子查询返回 NULL，下一层用它做 WHERE 条件，整条链就失效，且无提示
• 执行计划不可信：EXPLAIN 显示 DEPENDENT SUBQUERY，但真实耗时要看 EXPLAIN ANALYZE ——常出现“预估 1 行，实际扫描 20 万行”
• 无法下推条件：你没法把外层的 WHERE status = 'paid' 自动下推到三层深的子查询里，只能靠人工重写，极易遗漏

真正需要避免的不是 JOIN，而是没索引的 JOIN、跨类型隐式转换的 JOIN、驱动顺序错误的 JOIN。标量子查询不是“轻量替代”，它是“受限特例”。一旦你开始想“怎么嵌套三层”，说明该重构为 JOIN 或 CTE 了。