GROUP BY 与 HAVING

先把问题放回真实系统

我们不从术语表开始。设想你正在维护一个已有用户、并发请求和历史数据的系统，今天必须对“GROUP BY 与 HAVING”作出设计决定。一个选择看起来能跑，并不表示它在重复数据、NULL、并发、崩溃或规模扩大后仍正确。上一节建立了本章的语言，本节把它推进到可执行判断。本节真正要回答的是：怎样把直觉写成数据库能够执行、我们能够反查的规则。

先给出本节主张：GROUP BY 定义结果粒度，聚合函数压缩每组；WHERE 过滤原始行，HAVING 过滤聚合后的组。这句话包含对象、约束和结果三层。学习时请分别圈出“我们在研究什么”“什么条件不能省”“成功时能保证什么”。如果只记最后一个名词，遇到题目换一张表就会失效；如果能把三层说清，SQL 语法变化也不会妨碍推理。

机制：从状态、操作到可验证结果

把数据库看成状态 $D$。一次读操作从 $D$ 提取满足条件的关系，一次写操作把 $D$ 变为 $D^{\prime }$。本节的核心规则是：SELECT 中非聚合列必须由分组键函数决定；先写一句‘一行代表什么’。它不是装饰性公式，而是一份检查清单：先确认输入对象和粒度，再列成立条件，随后执行变换，最后核对输出模式、行数、单位或不变量。

针对“GROUP BY 与 HAVING”，第一步先写一句“一行代表什么”，第二步标出键、谓词或事务边界，第三步预测结果数量与失败情形，第四步才运行 SQL 或实验。数据库题最常见的失误不是少写一个关键字，而是从一开始就把结果粒度、量词或可见性理解错了。机制推演必须能解释成功样例，也必须能解释一个反例为何被拒绝。

完整例子：边做边验

考虑这个场景：找至少选 3 门且平均分≥85 的学生：WHERE 排除无效成绩，按 student_id 分组，再 HAVING COUNT 与 AVG。先不要急着提交答案。请在草稿上列出初始表、候选键和目标输出；如果涉及并发，再列出两个事务的操作顺序；如果涉及成本，再把记录数换算成页数或中间结果行数。随后按“SELECT 中非聚合列必须由分组键函数决定；先写一句‘一行代表什么’”逐项执行。每完成一步就问：结果中的一行现在代表什么？是否出现重复？NULL 会怎样？失败发生在此处时能否恢复？

一个合格的“GROUP BY 与 HAVING”演算应同时留下三类证据。其一是结果证据，例如确定的行集合、数值、查询计划或事务历史；其二是边界证据，要从“找至少选 3 门且平均分≥85 的学生：WHERE 排除无效成绩，按 student_id 分组，再 HAVING COUNT 与 AVG”继续构造空表、重复键、并列值、网络超时或崩溃点；其三是解释证据，即为什么本节规则“SELECT 中非聚合列必须由分组键函数决定；先写一句‘一行代表什么’”能支持所选算子、索引、隔离或恢复策略。只展示最终截图，无法区分理解与偶然成功。

在线练习：先预测，再运行，再解释

请先完成“GROUP BY 与 HAVING”绑定的单选题，识别“GROUP BY 定义结果粒度，聚合函数压缩每组；WHERE 过滤原始行，HAVING 过滤聚合后的组”中的必要条件；再完成多选题，把完整证据链与听起来正确的口号分开；最后按“SELECT 中非聚合列必须由分组键函数决定；先写一句‘一行代表什么’”完成计算或 SQL 推演题，提交步骤与结论。若本章附有 Python sqlite3 代码关卡，还要从标准输入建立内存数据库并通过不少于四组测试，不能用伪代码冒充运行结果。

围绕“找至少选 3 门且平均分≥85 的学生：WHERE 排除无效成绩，按 student_id 分组，再 HAVING COUNT 与 AVG”的自主练习也按三轮做。第一轮不运行，手算结果和行数；第二轮在 SQLite 中创建能核验“GROUP BY 与 HAVING”的最小数据，至少含正常、空值、重复企图和边界四类样例；第三轮故意破坏“SELECT 中非聚合列必须由分组键函数决定；先写一句‘一行代表什么’”中的一个连接条件、约束或事务顺序，观察错误如何暴露。把预测与实际不一致之处记入课程笔记，这比抄一遍正确 SQL 更有价值。

易错点与调试路线

学习“GROUP BY 与 HAVING”时最危险的捷径，是看到熟悉词就套固定写法，却没有核对本题的键、基数、NULL 语义、工作负载或故障模型。调试时不要同时改很多地方：先缩成最小反例，打印每个中间关系的模式与行数；再检查约束是否真的生效；最后比较计划或并发历史。每次修改只验证一个假设，并保留修改前后的证据。

“GROUP BY 与 HAVING”还有一个工程边界要记住：数据库替我们执行声明的规则，却不能猜出没有声明的业务语义。本节所说的“GROUP BY 定义结果粒度，聚合函数压缩每组；WHERE 过滤原始行，HAVING 过滤聚合后的组”若只存在产品经理脑中，任何索引或隔离级别都不会自动补上它。应根据“SELECT 中非聚合列必须由分组键函数决定；先写一句‘一行代表什么’”把规则落为唯一键、检查约束、事务条件、触发器或可审计的应用协议，并为拒绝路径写测试。

自检与本节收束

合上页面，用自己的话回答四问：一，“GROUP BY 与 HAVING”处理的对象是什么；二，规则“SELECT 中非聚合列必须由分组键函数决定；先写一句‘一行代表什么’”依赖哪些条件；三，在例子“找至少选 3 门且平均分≥85 的学生：WHERE 排除无效成绩，按 student_id 分组，再 HAVING COUNT 与 AVG”中，哪一步最容易得到表面正确但语义错误的结果；四，怎样用一个反例推翻错误实现。任何一问说不完整，都应回到机制或实验，而不是继续背下一页。

下一节会在这个结论上继续增加一个约束或更真实的系统条件。回看“GROUP BY 与 HAVING”，你应该带走的不是一串孤立名词，而是一种稳定动作：围绕“GROUP BY 定义结果粒度，聚合函数压缩每组；WHERE 过滤原始行，HAVING 过滤聚合后的组”定义粒度，声明不变量，按“SELECT 中非聚合列必须由分组键函数决定；先写一句‘一行代表什么’”推演机制，用最小数据运行，再用反例和故障检查边界。这套动作会贯穿关系模型、SQL、索引、优化、事务、恢复和分布式数据库。