子查询能替代JOIN，但不可一概而论；必须用子查询的场景包括：按行计算衍生值（如最新订单时间）、WHERE中引用聚合值（如高于用户平均订单金额）、主表每行需标量结果；相关子查询因逐行执行性能远低于非相关子查询。
子查询能替代 JOIN 吗？什么时候必须用子查询
不能一概而论。子查询和 JOIN 解决的是不同维度的问题：子查询适合「按行计算衍生值」，比如某用户订单数、最近一笔订单时间；JOIN 更适合「横向拼接关联数据」。强行用子查询替代多表 JOIN 做汇总统计，容易触发重复计算或性能暴跌。
典型必须用子查询的场景：
• 统计每个用户的最新订单时间（需 MAX(order_time) 按用户分组，但又不想写 GROUP BY 破坏主查询结构）
• 在 WHERE 中过滤出「订单金额高于该用户平均值」的记录
• 主表每行需要一个标量结果（如 (SELECT COUNT(*) FROM orders o WHERE o.user_id = u.id)）
相关子查询 vs 非相关子查询，性能差十倍不止
关键区别在子查询是否引用外层表字段：
• 非相关子查询（如 (SELECT AVG(amount) FROM orders)）只执行一次，快
• 相关子查询（如 (SELECT COUNT(*) FROM orders o WHERE o.user_id = u.id)）对主表每一行都重执行，数据量大时极易拖慢
实操建议：
• 优先把相关子查询改写成 LEFT JOIN + GROUP BY（例如用 JOIN (SELECT user_id, COUNT(*) cnt FROM orders GROUP BY user_id) t ON t.user_id = u.id）
• 若必须保留相关子查询，确保子查询中 WHERE 条件字段有索引（如 orders(user_id)）
• MySQL 8.0+ 可用 LATERAL（PostgreSQL/Oracle 早支持），让优化器更好处理嵌套聚合
多表汇总统计时，子查询常踩的三个坑
常见错误现象：
• 返回多行导致 Subquery returns more than 1 row 错误（标量子查询里用了没加 LIMIT 1 或没 GROUP BY）
• NULL 值被忽略，汇总总数变少（比如 SUM() 遇到全 NULL 返回 NULL，不是 0）
• 外层 GROUP BY 和子查询逻辑冲突（如主查询按日期分组，子查询却按用户算平均值，结果错乱）
规避方法：
• 标量子查询务必保证单值：用 COALESCE((SELECT ...), 0) 或 (SELECT MAX(x) FROM ...) 显式兜底
• 汇总类子查询优先放 FROM 子句（即派生表），避免在 SELECT 列表里堆多个相关子查询
• 测试时先单独运行子查询，确认返回行数和数据类型匹配外层预期
MySQL 和 PostgreSQL 的子查询语法差异点
大部分基础语法一致，但关键细节影响实操：
• MySQL 5.7 不支持在 FROM 子句中直接使用相关子查询（会报错 This version of MySQL doesn't yet support 'LIMIT & IN/ALL/ANY/SOME subquery'），得先用变量或临时表绕过
• PostgreSQL 允许在 SELECT 中写多列子查询（如 (SELECT name, status FROM users WHERE id = o.user_id)），MySQL 不行，必须拆成多个标量子查询
• 两者对 EXISTS 子查询的优化策略不同：PostgreSQL 常提前终止，MySQL 有时会扫完整表——检查执行计划时重点看 Extra 列是否含 Using where; Using index
建议：
• 跨数据库迁移时，把复杂子查询抽成 CTE（WITH 子句），可读性和兼容性都更好
• 在 PostgreSQL 中，用 ARRAY_AGG() 或 STRING_AGG() 替代多行子查询拼字符串，比反复调用相关子查询高效得多
SELECT u.name, (SELECT COUNT(*) FROM orders o WHERE o.user_id = u.id) 和 SELECT u.name, COALESCE(t.cnt, 0) FROM users u LEFT JOIN (SELECT user_id, COUNT(*) cnt FROM orders GROUP BY user_id) t ON t.user_id = u.id 的执行路径、内存占用、锁行为都完全不同。 
