相关子查询不能含GROUP BY，因其必须返回单值；正确写法是靠WHERE精准定位分组并聚合。适用于取每组非聚合值，统计类宜用LEFT JOIN+GROUP BY；需防NULL、索引缺失及重复执行性能问题。
相关子查询不能替代 GROUP BY，但能为每组生成一个标量值；关键在于子查询必须依赖外层行、不带 GROUP BY、且 WHERE 条件精准覆盖分组粒度。
相关子查询里为什么不能写 GROUP BY
标量子查询（括号里的 SELECT）只允许返回 0 或 1 行，而 GROUP BY 会按分组键拆出多行结果。比如 (SELECT COUNT(*) FROM orders o WHERE o.user_id = u.id GROUP BY o.user_id) 在 MySQL 中直接报错 Subquery returns more than 1 row——这不是语法错误，是语义冲突：你让数据库“对当前用户返回一个数”，但它却试图返回“每个 user_id 对应一个数”。
- 子查询执行时，外层的
u.id是单个值，所以子查询只需统计这一组数据，根本不需要再分组 - 正确写法是去掉
GROUP BY，只靠WHERE o.user_id = u.id定位本组，再用COUNT(*)或SUM(amount)聚合 - 如果外层是按
region分组，子查询 WHERE 就得写WHERE region = t1.region，不能错用user_id
什么时候该用相关子查询，而不是 LEFT JOIN + GROUP BY
相关子查询适合“轻量附加字段”场景，比如主查询已按用户分组，只想额外加一列「该用户最近一笔订单金额」；而 LEFT JOIN + GROUP BY 更适合统计型字段（如订单总数、总金额），性能更好也更易读。
- 用相关子查询：需要取每组中某一行的非聚合值（如最新时间、最大金额、某个状态字段），且不想改变主查询结构
- 用
LEFT JOIN+GROUP BY：统计类指标（COUNT、SUM、AVG），尤其是数据量大或需保证 NULL 用户也显示 0 时 - 相关子查询在 MySQL 5.7+ 和 PostgreSQL 中支持良好；SQLite 支持但慢；旧版 MySQL 可能触发
Dependent subquery告警，影响优化器选择
NULL 和除零问题最容易被忽略
相关子查询没匹配到数据时返回 NULL，一旦参与计算（比如除法、AVG、CASE WHEN），整行结果就变成 NULL，报表里表现为“莫名少了几行”，排查困难。
- 永远用
COALESCE((SELECT ...), 0)包住子查询，别依赖默认行为 - 避免写类似
(SELECT SUM(vip_amount) FROM orders WHERE ...) / SUM(total_amount)这种表达式，分子为NULL时整条记录消失 - 测试时可手动删掉某分组下全部关联数据，看结果是否“缺行”——这是快速定位该问题的土办法
性能崩在 WHERE 没走索引
相关子查询每行执行一次，如果子查询里的 WHERE 条件字段没索引，1000 行外层结果 = 1000 次全表扫描。
- 驱动字段（如
user_id = u.id）必须落在索引最左前缀上；若子查询条件是WHERE user_id = u.id AND status = 'shipped'，索引就得建为(user_id, status) - 不要在子查询里 JOIN 大表；先让子查询只输出 ID + 聚合值，外层再关联维度表
- 如果同一个子查询逻辑要复用多次（比如既算 VIP 订单数又算总订单数），优先改用 CTE 或派生表，避免重复执行
