GROUP BY + HAVING 配合 COUNT 可校验主键是否拥有完整关联子集，因 WHERE 在分组前筛行、无法统计数量，INNER JOIN 仅保证存在性而不验证数量，必须先按主键分组再用 HAVING 对 COUNT(*) 或 COUNT(DISTINCT) 结果过滤。
GROUP BY + HAVING 配合 COUNT 实现子集完整性校验
要判断某个主键是否“拥有完整关联子集”，本质是检查它在关联表中是否具备预期数量的匹配行。比如：一个课程 course_id 应该恰好有 3 个必修章节，那只有当它在 chapters 表中出现且 COUNT(*) = 3 时才算“完整”。这不能靠 WHERE 或 JOIN 单独完成，必须用 GROUP BY 分组后，再用 HAVING 对聚合结果做条件过滤。
为什么不能只用 WHERE 或 INNER JOIN？
WHERE 是在分组前筛行，无法表达“每个主键对应多少条子记录”；INNER JOIN 只能保证存在关联，但不保证数量达标——哪怕某主键只关联了 1 条记录，也会被包含进来。
- 错误写法：
SELECT course_id FROM courses c INNER JOIN chapters ch ON c.course_id = ch.course_id WHERE ch.status = 'required'→ 漏掉数量判断 - 正确思路：先按
course_id分组，再用HAVING COUNT(*) = 3筛出刚好满足数量的组 - 注意：若子表中存在重复或脏数据，
COUNT(*)会把它们全算进去，建议先确认UNIQUE约束或加DISTINCT
处理多条件子集（如“必须含 A、B、C 三类记录”）
当“完整”不是指数量相等，而是要求同时存在多个特定值（例如：一个订单必须同时包含商品类型 'shipping'、'tax'、'discount' 各一条），COUNT(DISTINCT type) 就比单纯 COUNT(*) 更可靠。
- 示例：
SELECT order_id FROM order_items GROUP BY order_id HAVING COUNT(DISTINCT item_type) = 3 AND COUNT(*) = 3 - 第一个条件确保三种类型都出现，第二个条件防止某类型重复导致总数超 3
- 如果允许重复但必须至少各有一条，可只保留
COUNT(DISTINCT item_type) = 3 - MySQL 8.0+ 中还可配合
JSON_CONTAINS或窗口函数做更灵活判断，但复杂度陡增，多数场景HAVING+COUNT(DISTINCT)已足够
LEFT JOIN 后聚合容易踩的 NULL 坑
如果主表某主键在子表中完全无匹配，LEFT JOIN 会返回 NULL 行，此时 COUNT(*) 为 1（因为 LEFT JOIN 仍生成一行），而 COUNT(sub_id) 才是 0。这点极易误判。
- 错误：
SELECT p.id FROM products p LEFT JOIN inventory i ON p.id = i.product_id GROUP BY p.id HAVING COUNT(*) = 0→ 永远不成立 - 正确：
HAVING COUNT(i.product_id) = 0（利用 COUNT 忽略 NULL 的特性） - 更安全写法：
HAVING COALESCE(COUNT(i.product_id), 0) = 0，显式强调空值处理逻辑 - 实际开发中，建议优先用
NOT EXISTS替代 LEFT JOIN + COUNT == 0，语义更清晰、性能通常更好
真正难的不是写出 HAVING 条件，而是事先厘清“完整”的定义：是数量固定？是类型齐全？还是状态组合唯一？一旦定义模糊，COUNT 和 COUNT(DISTINCT) 的选择就会出错，后续所有聚合结果都不可信。
