GROUP BY核心规则是SELECT中非聚合字段必须出现在GROUP BY子句中或包裹于聚合函数内；WHERE用于分组前过滤行，HAVING用于分组后过滤组；多字段分组时NULL被视为同一组，空字符串则独立；避免在GROUP BY字段上使用函数以防索引失效。
GROUP BY 不是万能的分组工具，用错条件或漏写字段会直接报错或返回错误结果。
GROUP BY 后 SELECT 列必须是分组键或聚合函数
常见错误是 SELECT 了未出现在 GROUP BY 中的非聚合列，比如 SELECT user_id, name, COUNT(*) FROM orders GROUP BY user_id —— 这在 MySQL 5.7+ 和所有标准 SQL 引擎（PostgreSQL、SQL Server）中都会报错，因为 name 对每个 user_id 可能不唯一。
- 正确写法：把
name加进 GROUP BY，或用聚合函数包裹，如MAX(name) - MySQL 旧版本（5.6 及之前）允许这种写法，但结果不可靠——它随便挑一个
name返回，不是业务想要的“对应用户名” - 如果想查每个用户的最新订单时间，得用
MAX(order_time)，而不是裸写order_time
WHERE 和 HAVING 的分工必须分清
WHERE 过滤行，HAVING 过滤分组，顺序不能颠倒。先有 WHERE 筛原始数据，再 GROUP BY 分组，最后 HAVING 对聚合结果做条件判断。
- 要查“下单次数 ≥ 5 的用户”，必须写
HAVING COUNT(*) >= 5，写在 WHERE 里会报错（COUNT(*)在 WHERE 阶段还不存在） - 要查“2024 年的订单中下单次数 ≥ 5 的用户”，WHERE 先筛
order_time >= '2024-01-01'，再 GROUP BY + HAVING - HAVING 支持的表达式受限于 SELECT 中出现的聚合列，不能引用未聚合的原始字段
多字段分组要注意 NULL 和空字符串的归并行为
当按多个字段分组（如 GROUP BY region, city），NULL 值会被当作同一组处理，哪怕实际含义不同；而空字符串 '' 和 NULL 是两个独立值，不会被合并。
- 如果
city有 NULL 和''，它们会分属两组，可能造成统计偏差 - 保险做法是提前清洗：用
COALESCE(city, 'unknown')或NULLIF(city, '')统一 NULL 表示 - 某些数据库（如 PostgreSQL）对 NULL 的排序和分组行为更严格，MySQL 默认宽松，但开启
ANSI_QUOTES模式后也会收紧
性能敏感时避免在 GROUP BY 字段上用函数
比如 GROUP BY DATE(created_at) 或 GROUP BY UPPER(email) 会导致索引失效，全表扫描不可避免。
- 优先在 WHERE 条件中用函数预过滤，分组字段尽量保持原始列名
- 若必须按日期分组，建一个生成列（generated column）并加索引，如 MySQL 的
created_date DATE AS (DATE(created_at)) STORED - 聚合量极大（千万级以上）时，考虑提前物化汇总表，而非每次实时 GROUP BY
最常被忽略的是 GROUP BY 的语义边界：它只定义“哪些行算一组”，不保证组内数据顺序，也不控制每组返回哪一行——想取每组最新/最贵/第一条记录，得配合窗口函数或子查询，不能只靠 GROUP BY 解决。
