GROUP BY 后COUNT()不返回0或NULL，而是跳过空分组；需LEFT JOIN补全维度表并用COALESCE(COUNT(), 0)实现显示0。
GROUP BY 后 COUNT() 返回 0 还是 NULL？
聚合函数在空组里默认不返回行，不是返回 COUNT() 为 0，更不是 NULL；它直接跳过该分组。想让“没有数据的分组也显示 0”，必须用 LEFT JOIN 补全维度表，再配合 COALESCE(COUNT(...), 0)。
- 常见错误：写
SELECT dept, COUNT(*) FROM emp GROUP BY dept，发现某些部门没出现在结果里——不是数据丢了，是压根没记录，GROUP BY不凭空造行 - 正确做法：先有部门主表
dept，再LEFT JOIN emp ON dept.id = emp.dept_id，然后GROUP BY dept.name -
COUNT(*)和COUNT(字段)行为不同：COUNT(字段)会忽略该字段为NULL的行，COUNT(*)统计所有非空行（包括字段全为NULL的行）
AVG() 和 SUM() 遇到 NULL 怎么办？
AVG() 和 SUM() 默认自动过滤 NULL 值，不报错也不中断，但容易误判“平均值偏低”是业务问题，其实是字段本身大量缺失。
- 典型现象：查订单平均金额，结果比预期低很多，一查发现
amount字段在退单、草稿单里是NULL，被静默跳过了 - 验证方法：对比
COUNT(*)和COUNT(amount)，差值就是NULL行数 - 如果想把
NULL当 0 参与计算，得显式转换：AVG(COALESCE(amount, 0))，但注意这会拉低均值，业务语义可能不对 - MySQL 8.0+ 支持窗口函数，可搭配
AVG(...) OVER (PARTITION BY ...)实现分组内均值，但依然跳过NULL
MAX()/MIN() 在字符串和日期上怎么比？
它们按排序规则（collation）逐字符比较字符串，按时间戳大小比较日期，不关心“是否合理”，只管字典序或数值大小。
- 字符串陷阱：
MAX(name)返回字典序最大的名字，比如'Zhang'>'li'（因为大写ZASCII 值大于小写l），跟实际拼音顺序无关 - 日期安全：只要列类型是
DATE、DATETIME或TIMESTAMP，MAX(created_at)就是最新时间，没问题 - 隐患场景：用
VARCHAR存日期（如'2023-01-01'），MAX()虽然也能“碰巧”对，但一旦格式不统一（'1/1/2023'），结果就不可靠 - 建议：宁可用
STR_TO_DATE()转一次再聚合，也别赌字符串格式一致性
WHERE 和 HAVING 混用时为什么总报错？
WHERE 过滤原始行，HAVING 过滤分组后结果，二者阶段不同，不能互换；最常踩的坑是把聚合函数塞进 WHERE。
- 错误写法：
SELECT dept, COUNT(*) FROM emp WHERE COUNT(*) > 5 GROUP BY dept→ 报错Invalid use of group function - 正确写法：把条件挪到
HAVING——SELECT dept, COUNT(*) FROM emp GROUP BY dept HAVING COUNT(*) > 5 - 性能注意：
WHERE越早过滤掉无用行，GROUP BY开销越小；HAVING是最后一步，无法利用索引加速 - 特殊需求：想先筛人再统计，比如“只统计在职员工”，就把
status = 'active'放WHERE；想“只看员工数超 10 的部门”，就放HAVING
聚合函数本身很稳，真正出问题的地方，往往不在函数怎么写，而在你默认了数据“应该有”或“应该非空”。多看一眼 COUNT(*) 和 COUNT(字段) 的差值，比反复调 AVG() 参数有用得多。
