join和group by必须严格配合：left join后用count(u.id)而非count(*)统计，否则null行仍被计数；inner join需确保select中所有非聚合字段均出现在group by中，且多表同名字段必须加前缀明确归属。
直接说结论：JOIN 和 GROUP BY 必须配合使用，但顺序、连接类型、字段选择稍有偏差，结果就可能全错——尤其是 NULL 值处理和非聚合字段报错这两处，90% 的人栽在这儿。
LEFT JOIN + GROUP BY 统计时为什么 count(*) 总是 1？
这是最常见的错觉：你写了 LEFT JOIN 想查“每个部门有多少员工”，结果发现每个部门只显示 1 条，COUNT(*) 却是 1。问题不在语法，而在逻辑误解。
-
LEFT JOIN确保左表（如dept）所有行都出现，但若右表（如user）没匹配记录，那整行右表字段全为NULL，而COUNT(*)仍会数这一行（因为它不是空行，只是右表字段为空） - 真正该用的是
COUNT(user.id)或COUNT(user.name)—— 这些非空字段在无匹配时为NULL，COUNT会自动忽略 - 如果想把“0 员工的部门”也体现为数字 0，必须写
COUNT(user.id)，不能用COUNT(*)
示例：
SELECT d.dept_name, COUNT(u.id) AS user_count<br>FROM dept d<br>LEFT JOIN user u ON d.id = u.dept_id<br>GROUP BY d.id, d.dept_name;
INNER JOIN 后 GROUP BY 报错 “Expression #1 of SELECT list is not in GROUP BY clause”
MySQL 5.7+ 默认开启 sql_mode=only_full_group_by，它强制要求：SELECT 列表里的每个非聚合字段，必须显式出现在 GROUP BY 子句中。
- 错误写法：
SELECT d.dept_name, u.name, COUNT(*) FROM dept d INNER JOIN user u ... GROUP BY d.id——u.name既没聚合也没分组，直接报错 - 正确做法只有两种：要么删掉
u.name；要么把它加进GROUP BY（但通常没意义，因为一个部门多人，GROUP BY d.id, u.name就变成按人分组了） - 如果真需要展示某个代表值（比如每个部门任一员工名），可用
MAX(u.name)或GROUP_CONCAT(u.name)，它们是合法聚合表达式
多表 JOIN 后 GROUP BY 字段要不要带别名或前缀？
要，而且必须一致。尤其当多表有同名列（比如 id、name）时，不加表前缀会导致歧义甚至执行失败。
-
GROUP BY id是危险的——数据库不知道你要按哪张表的id分组 - 必须写成
GROUP BY d.id或GROUP BY u.dept_id，且这个字段还得在 SELECT 中出现（或被聚合） - 如果
SELECT里用了别名（如d.dept_name AS dept），GROUP BY里不能写dept，得写原始字段d.dept_name或别名对应的源字段 - MySQL 不支持在
GROUP BY中直接用列别名（除非是极老版本），这点和 PostgreSQL 不同
统计结果里出现重复分组或漏掉数据？检查 JOIN 条件是否漏了索引
逻辑没错，但数据量一大就出怪现象：有的分组条数忽高忽低，或者某些本该出现的组合完全消失。大概率是 JOIN 条件字段没建索引，导致隐式类型转换或临时表膨胀，进而影响分组边界。
- 典型场景：
user.dept_id是INT，但dept.id是VARCHAR，JOIN 时 MySQL 会隐式转成字符串比较，索引失效，分组可能因排序不稳定而错乱 - 另一个坑：
ON u.dept_id = d.id中任意一边用了函数，比如ON CAST(u.dept_id AS CHAR) = d.id，索引同样失效 - 验证方法：对 JOIN 字段执行
EXPLAIN，看type是否为ref或eq_ref，key是否显示实际使用的索引
最易被忽略的一点：GROUP BY 的语义是“先 JOIN 再分组”，不是“先分组再 JOIN”。这意味着所有 JOIN 结果集生成后才开始分组——所以中间产生的冗余行（比如一对多导致的重复部门行）会被如实计入聚合，而不是按你脑内预设的“部门维度”自动去重。想控制这个，得靠 JOIN 类型和聚合函数本身，而不是幻想 GROUP BY 会智能合并。
