MySQL 的
GROUP BY本身**不是集合操作（set operation）**，它属于**分组聚合操作**；所谓“分组集合”是中文语境里对
GROUP BY+ 聚合函数组合效果的一种通俗叫法，并非 SQL 标准中的集合运算（如
UNION、
INTERSECT、
EXCEPT）。
为什么 GROUP BY 不是集合操作？
SQL 中真正的集合操作必须满足：操作对象是**两个或多个结果集（即表或子查询返回的行集合）**，且按数学集合规则（无序、去重、同结构）进行并、交、差。而
GROUP BY的作用对象是**单个结果集内部的行**，它不合并多个查询结果，也不比较集合关系——它只是把行按列值归类，再对每类执行聚合计算。
UNION是集合操作：合并两个 SELECT 的结果，自动去重（
UNION ALL除外）
GROUP BY year, country不是：它没拿另一个表来“做交集”或“求差”，只是在当前数据里切块统计 标准 SQL 中，集合操作只能出现在顶层查询或子查询的并列位置，不能嵌套在
GROUP BY子句中
“分组集合”这个说法到底指什么？
这是开发者对
GROUP BY实际用途的简化描述，重点在“把相同值的行聚合成一个逻辑集合，再对这个集合算总数/平均值/拼接字符串等”。它强调的是**分组后每个组视为一个数据单元**，类似集合的“元素打包”行为，但技术上仍是行分组 + 聚合函数调用。 常见场景：
SELECT city, COUNT(*) FROM users GROUP BY city→ 每个
city值对应一个用户数“集合结果” 搭配
GROUP_CONCAT()更像集合：如
GROUP_CONCAT(name SEPARATOR ', ')把组内所有 name 合成一个字符串集合表示
WITH ROLLUP会额外生成“空值汇总行”，本质是分组层级的上卷（roll-up），不是集合运算，但容易被误认为“并入了新集合”
容易踩的坑：GROUP BY 和 DISTINCT 的混淆
很多人以为
GROUP BY col等价于
SELECT DISTINCT col，这是危险误解。前者必须配合聚合函数（否则 MySQL 5.7+ 严格模式报错），后者直接去重返回原始行。 错误写法：
SELECT name, age FROM student GROUP BY city→
name和
age不在
GROUP BY列中，也不是聚合字段，MySQL 8.0 默认拒绝（
ONLY_FULL_GROUP_BY开启） 正确做法：要么补全
GROUP BY name, age，要么用聚合函数包裹，如
MAX(age)
DISTINCT不触发分组逻辑，也不支持聚合，纯去重；
GROUP BY必须有聚合意图，即使只写
COUNT(*)也表明“我要按这列分组统计”
实际开发中怎么安全用好 GROUP BY？
核心原则：**明确分组意图，显式声明所有非聚合字段**。MySQL 允许“功能依赖”下的宽松写法（如主键列可省略在 GROUP BY 中），但跨版本兼容性和可读性差，建议一律显式写出。
开启ONLY_FULL_GROUP_BY（默认已开）：避免隐式随机取值导致结果不可靠 多表 JOIN 后分组：先确认分组字段来源表，避免因 JOIN 产生笛卡尔膨胀后再分组，导致聚合值翻倍 想实现“每个城市最新一条记录”？别直接
GROUP BY city+
MAX(created_at)—— 这拿不到整行，得用窗口函数或相关子查询 性能提示：
GROUP BY字段最好有索引，尤其是复合索引要匹配最左前缀（如
INDEX(city, status)支持
GROUP BY city, status）
SELECT city, COUNT(*) AS user_count, AVG(age) AS avg_age, GROUP_CONCAT(DISTINCT job ORDER BY job SEPARATOR ' | ') AS jobs FROM users WHERE status = 'active' GROUP BY city HAVING COUNT(*) > 10;
真正复杂的点从来不在语法本身，而在于：你是否清楚每一行输出，到底是来自哪个物理分组、聚合函数是否覆盖了所有业务语义、以及当数据分布倾斜时（比如 90% 用户都在“北京”），
GROUP BY的结果是否还具备统计代表性。
