JOIN必须在GROUP BY之前完成，SQL执行顺序固定为FROM→JOIN→WHERE→GROUP BY；LEFT JOIN后需用COALESCE处理NULL，GROUP BY字段须覆盖SELECT中所有非聚合列，UNION ALL后聚合必须用子查询包裹并指定别名。
JOIN之后GROUP BY必须写在最外层
多表连接后直接在JOIN语句末尾加GROUP BY，语法上就通不过——SQL执行顺序固定为 FROM → JOIN → WHERE → GROUP BY，所以GROUP BY只能出现在所有JOIN完成之后、且不能嵌套在JOIN中间。
常见错误写法：SELECT u.name FROM users u JOIN orders o ON u.id = o.user_id GROUP BY u.name 看似没问题，但一旦加了第三个表或子查询，就容易误把GROUP BY当成“局部聚合”，结果漏数据或报错。
- 正确结构是：先完整写出所有
JOIN和WHERE，再统一GROUP BY - 如果某张表只用于补充信息（如部门名称），不要提前对它做聚合，否则LEFT JOIN会失效
- MySQL 5.7+默认启用
ONLY_FULL_GROUP_BY，SELECT u.name, COUNT(o.id) FROM users u LEFT JOIN orders o ... GROUP BY u.name是合法的；但漏掉u.id（而SELECT里又用了）就会报错
LEFT JOIN + GROUP BY必须显式处理NULL值
用LEFT JOIN保留主表全部记录时，右表字段在聚合中出现NULL是常态。但COUNT(*)、COUNT(字段)、SUM(字段)对NULL的处理逻辑完全不同，不加区分会导致统计值失真。
-
COUNT(*)统计每组总行数（含右表无匹配的行） -
COUNT(o.id)只统计右表有匹配的行数，没订单的用户这一列就是0 -
SUM(o.amount)遇到全NULL组会返回NULL，前端渲染常崩；应写成COALESCE(SUM(o.amount), 0) - 别依赖
IFNULL或ISNULL——函数名跨数据库不一致，COALESCE是SQL标准且兼容性最好
多表聚合时GROUP BY字段必须覆盖所有非聚合列
不只是“看起来要写全”，而是数据库强制要求：只要SELECT里出现了一个未被聚合函数包裹的列，它就必须出现在GROUP BY中。否则MySQL直接报错，PostgreSQL和SQL Server也默认拒绝。
- 例如：
SELECT u.id, u.name, COUNT(o.id) FROM users u LEFT JOIN orders o ...→GROUP BY u.id, u.name缺一不可 - 如果业务上确认
u.name在u.id下唯一，也不能只写GROUP BY u.id（除非关掉ONLY_FULL_GROUP_BY，但这是掩盖问题） - 用
MAX(u.name)替代u.name可行，但前提是能100%保证该字段在组内恒定；否则可能取到错误行的值
UNION ALL后聚合必须用子查询包裹并指定别名
想把2024年和2025年的订单状态合并再统计频次？不能写SELECT status FROM orders_2024 UNION SELECT status FROM orders_2025 GROUP BY status——这会报语法错误，因为UNION产出的是集合操作结果，不是可直接GROUP BY的查询主体。
- 必须写成子查询：
SELECT status, COUNT(*) FROM (SELECT status FROM orders_2024 UNION ALL SELECT status FROM orders_2025) AS t GROUP BY status -
AS t别名不可省，MySQL/PG/SQL Server全要求 - 优先用
UNION ALL：避免隐式去重干扰计数，尤其当字段类型存在隐式转换（比如VARCHAR和CHAR混用）时，UNION可能误判“相同值” - 子查询里的列名以第一个
SELECT为准，后续SELECT中的别名（如SELECT user_id AS id）只是语义提示，不影响最终列名
实际写的时候，最容易被忽略的是列类型对齐和NULL处理边界。比如两个UNION ALL子句里一个用VARCHAR(50)，一个用TEXT，多数数据库能隐式转，但GROUP BY阶段可能因排序规则差异导致分组断裂；又比如LEFT JOIN后直接SUM()却不COALESCE，查出来一堆NULL，下游程序一解包就报错。这些都不是语法问题，而是数据语义层面的断点。
