多维度聚合是对(A,B,C)联合键一次性分组，非嵌套；GROUP BY字段必须与SELECT中非聚合列完全一致，否则触发only_full_group_by错误。
直接说结论：多维度聚合不是“先按 A 分组、再在每组里按 B 分组”，而是对 (A, B, C) 这个联合键做一次性分组；写错 GROUP BY 字段列表或漏掉非聚合列，会直接报 sql_mode=only_full_group_by 错误。
GROUP BY 多字段必须和 SELECT 中非聚合列完全一致
MySQL 5.7+ 默认启用严格模式，SELECT 里出现的每个非聚合字段，都得原样出现在 GROUP BY 列表中。比如你写：
SELECT city, payment_method, SUM(amount), COUNT(*) FROM orders GROUP BY city;
——这会报错，因为 payment_method 没进 GROUP BY，MySQL 不知道该取哪一行的值。
- 正确写法是：
GROUP BY city, payment_method - 别依赖旧版 MySQL 的“隐式随机取值”行为，它不可靠且已禁用
- 如果真想只按
city分组，但又想显示某个固定payment_method（比如“主支付方式”），得用子查询或窗口函数，不能硬塞进SELECT
多维分组 ≠ 嵌套分组，顺序只影响排序和取值逻辑
GROUP BY region, product_type 和 GROUP BY product_type, region 分组结果完全一样，都是生成所有 (region, product_type) 组合；但：
- 前者会让结果默认按
region升序、再按product_type升序排列（无ORDER BY时） - 如果用了
SELECT region, product_type, MAX(created_at)，且某组内product_type不唯一，MySQL 5.7+ 会直接拒绝执行，而不是随便挑一个 - 想看“华东”下各产品的销量，再加一层“华东总计”，别手写
UNION ALL，改用WITH ROLLUP或GROUPING SETS
COUNT(*) 和 COUNT(列名) 的 NULL 行处理差异很关键
统计订单数时，用 COUNT(*) 是对整行计数；而 COUNT(amount) 会跳过 amount IS NULL 的行——这两者在有空值的业务表里结果可能差很多。
- 查“各城市有效支付订单笔数”：用
COUNT(payment_id)（假设payment_id非空才代表成功） - 查“各城市总订单量（含待支付）”：必须用
COUNT(*) - 别用
COUNT(1)图省事，它和COUNT(*)效果相同，但语义不清，容易误导后续维护者
需要多层级小计？别拼 UNION，优先试 ROLLUP 或 GROUPING SETS
要同时输出「城市级」「大区级」「全国级」销售额，传统写法是三段 GROUP BY + UNION ALL，物理扫描表三次。现代 SQL 支持单次扫描解决：
-
GROUP BY city, region WITH ROLLUP会自动补上(city, region)、(city, NULL)、(NULL, NULL)三档 -
GROUPING SETS ((city), (region), ())更灵活，可精确控制要哪几组，还能配合GROUPING_ID()标识汇总层级 - 注意：MySQL 原生不支持
GROUPING SETS，但 8.0+ 支持WITH ROLLUP；PostgreSQL / ClickHouse / SparkSQL 全支持
真正容易被忽略的是：多维分组后，HAVING 是对聚合结果过滤，但 WHERE 是在分组前筛数据；很多人把时间范围条件错放 HAVING，导致全表先分组再丢弃，性能雪崩。
