子查询关联分组结果时必须加别名，MySQL、PostgreSQL、SQL Server均强制要求，否则报错“Every derived table must have its own alias”；常见错误是省略别名，正确写法需为子查询显式指定AS别名，且关联字段类型与NULL处理须严格一致。
子查询关联分组结果时，必须给子查询加别名
MySQL、PostgreSQL、SQL Server 都要求子查询（包括含 GROUP BY 的）在 FROM 或 JOIN 中出现时，必须有别名。否则直接报错，比如 MySQL 会提示 Every derived table must have its own alias。
常见错误写法：SELECT * FROM orders JOIN (SELECT user_id, COUNT(*) FROM order_items GROUP BY user_id) ON ... —— 缺少别名，语法不通过。
正确做法是立刻跟上一个有意义的别名：
SELECT u.name, cnt.item_count FROM users u JOIN ( SELECT user_id, COUNT(*) AS item_count FROM order_items GROUP BY user_id ) AS cnt ON u.id = cnt.user_id
WHERE 条件不能直接写在分组子查询里，得用 HAVING 或外层过滤
想筛出“下单超过 5 次的用户”，很多人会把 WHERE COUNT(*) > 5 写进子查询——这会报错，因为 COUNT(*) 是聚合结果，不能在 WHERE 中引用。
两种合法路径：
- 在子查询内用
HAVING：把HAVING COUNT(*) > 5放在GROUP BY后面 - 在外层用
WHERE：子查询照常分组，外层WHERE cnt.item_count > 5
推荐后者，逻辑更清晰，也方便后续加其他关联或计算；HAVING 适合纯筛选、不需保留原始分组字段的场景。
关联字段类型和 NULL 值要严格一致，否则匹配失败
子查询里的 user_id 如果是 INT，而主表 users.id 是 BIGINT，某些数据库（如 PostgreSQL）会拒绝隐式转换，导致 JOIN 结果为空；MySQL 虽可能自动转，但容易丢精度或误匹配。
NULL 值也容易被忽略：如果 order_items.user_id 允许为 NULL，那它参与 GROUP BY 会单独成一组，但和主表 JOIN 时，NULL = NULL 不成立，这组数据就彻底丢失。
稳妥做法：
- 确认两边字段类型完全一致（必要时用
CAST显式转换） - 子查询中加
WHERE user_id IS NOT NULL过滤掉空值，避免意外分组 - 若业务允许统计 NULL 用户，改用
LEFT JOIN并检查cnt.user_id IS NULL
性能敏感时，优先考虑 CTE 而非嵌套子查询
当分组逻辑复杂、且需要多次引用时（比如既要关联用户表，又要和订单主表再算一次平均金额），嵌套子查询会让优化器难以重用中间结果，执行计划可能重复扫描同一张表。
PostgreSQL 和 SQL Server 支持 CTE，MySQL 8.0+ 也支持，写起来更直观，且多数引擎会对 CTE 做物化优化：
WITH user_item_counts AS ( SELECT user_id, COUNT(*) AS cnt FROM order_items WHERE user_id IS NOT NULL GROUP BY user_id ) SELECT u.name, c.cnt, o.avg_amount FROM users u JOIN user_item_counts c ON u.id = c.user_id JOIN ( SELECT user_id, AVG(amount) AS avg_amount FROM orders GROUP BY user_id ) o ON u.id = o.user_id
CTE 名本身不是物理表，但语义清晰、易调试，比多层括号子查询更不容易漏括号或配错别名。
真正难的不是写法，而是想清楚：这个分组结果到底要不要去重？有没有未覆盖的 NULL 场景？关联后是否还需要补全缺失行？这些不提前理清，光调通语法也没用。
