子查询不能直接引用外层GROUP BY字段，因其仅可见原始行级数据；需显式传入分组键并确保WHERE条件覆盖分组粒度，注意NULL处理、索引优化及嵌套层级控制。
子查询里不能直接用外部 GROUP BY 字段
很多人写 SELECT 套子查询时，想在子查询里引用外层的分组字段，比如写成 (SELECT SUM(amount) FROM orders o2 WHERE o2.user_id = u.id) 却放在按 u.region 分组的主查询里——结果要么报错，要么逻辑错。因为子查询是独立执行的，它看不到外层 GROUP BY 后的聚合上下文，只认得到外层的原始行级数据。
正确做法是：把需要关联的字段显式传进去，且确保关联条件覆盖分组粒度。常见场景是「每个地区总销售额中，来自 VIP 用户的部分占比」这类带条件的分组内计算。
- 子查询必须能通过
WHERE精确匹配到当前分组对应的记录集（比如用region而不是user_id） - 如果分组键是复合的（如
(region, year)），子查询WHERE也得写全，漏一个就变成全表扫描或错误聚合 - MySQL 5.7+ 和 PostgreSQL 支持相关子查询，但 SQLite 不支持；若用在视图或 ORM 中，部分框架会自动展开为 JOIN，行为不一致
用子查询做条件分组求和时，NULL 值会吞掉整行
当子查询没匹配到数据，返回 NULL，而你又在主查询里写了类似 total_vip / total_all 这种除法，整行结果就会变 NULL——不是报错，而是静默消失。这在报表里特别隐蔽，看起来“少了几条数据”，其实只是被 NULL 过滤掉了。
典型错误写法：SELECT region, (SELECT SUM(amount) FROM orders WHERE vip=1 AND region=t1.region) / SUM(amount) FROM sales_summary t1 GROUP BY region。只要某个 region 下没有 VIP 订单，分子就是 NULL，除法结果为 NULL，再参与后续计算就断链了。
- 用
COALESCE(subquery, 0)包一层，强制补 0，而不是依赖数据库默认行为 - 避免在除法、
AVG()或CASE WHEN中直接嵌套可能返回NULL的子查询 - 测试时故意删掉某分组下的部分数据，看结果是否“少行”，这是快速定位该问题的土办法
子查询性能崩在 WHERE 条件没走索引
子查询每行都执行一次，如果子查询里的 WHERE 条件字段没索引，比如 WHERE status = 'shipped' AND created_at > '2024-01-01'，而 created_at 没建索引，那每次调用都在扫全表。1000 个分组 → 扫 1000 次全表，比直接 JOIN 慢一个数量级。
不是所有子查询都慢，关键看驱动字段是否落在索引最左前缀上。例如主查询按 category 分组，子查询用 WHERE category = t1.category AND type = 'sale'，那就要求索引是 (category, type)，反过来就不行。
- 用
EXPLAIN看子查询是否显示type=ALL（全表扫描） - 把子查询等价改写成
LATERAL JOIN（PostgreSQL）或JOIN ... ON（MySQL 8.0+），更容易走索引 - 如果子查询逻辑固定（比如总是算“近 30 天销售额”），优先考虑物化成临时表或 CTE，避免重复计算
GROUP BY 和子查询嵌套层级超过两层就难调试
三层嵌套很常见：主查询分组 → 子查询 A 算各组指标 → 子查询 B 在 A 里再套一层条件过滤。一旦出错，ERROR 1054 (42S22): Unknown column 这类提示根本看不出是哪一层丢了别名，或者哪个字段作用域越界。
比如在 MySQL 里，子子查询无法访问主查询的别名，但可以访问上一层子查询的别名——这个边界非常容易踩空。而且不同数据库对列可见性的处理略有差异，迁移到新版本或换引擎时容易突然报错。
- 给每一层子查询明确加别名，如
(SELECT ... FROM ...) AS sub1，然后只通过sub1.col引用，不依赖隐式作用域 - 把深层逻辑拆出来，先用 CTE 写清楚中间结果，再在主查询里引用，可读性和调试成本都低得多
- 别为了“看起来简洁”硬塞三层子查询，多一行
WITH换来的可维护性远高于嵌套技巧
真正麻烦的从来不是语法能不能写出来，而是改需求时发现子查询里混着业务规则、时间逻辑、状态判断，三者耦在一个括号里，谁都不敢动。
