GROUP BY不能与EXISTS直接联动实现群组级过滤，必须用CTE或派生表提前固化分组结果（如部门平均薪资、最高薪资），再通过JOIN或EXISTS关联主表，避免相关子查询导致的逐行重复计算和性能灾难。
GROUP BY 本身不能直接和 EXISTS 做“群组级”联动；必须把 EXISTS 拆到外层或用 CTE / 派生表提前固化分组结果，否则会触发相关子查询性能灾难。
EXISTS 子查询里不能直接引用 GROUP BY 的聚合结果
比如你想查「每个部门中薪资最高的员工」，然后只保留「该员工所在部门平均薪资 > 10000」的记录——不能写成：
SELECT * FROM emp e WHERE salary = (SELECT MAX(salary) FROM emp WHERE dept = e.dept) AND (SELECT AVG(salary) FROM emp WHERE dept = e.dept) > 10000;
这看似合理，但第二个子查询对每一行 e 都执行一次，10 万员工就是 10 万次全表扫描（哪怕加了索引也救不了）。更糟的是，它根本不是“群组过滤”，而是逐行判断。
- 相关子查询无法复用分组中间态，数据库不会自动缓存
AVG(salary)每个部门算一次的结果 - MySQL 5.7+ / PostgreSQL 在严格模式下可能报错或返回不可靠值（如
AVG对空组返回NULL，导致整行被过滤） - 子查询中若含
ORDER BY或LIMIT，在无GROUP BY上下文时行为不一致（例如取“最新一条”可能失效）
正确做法：先用 CTE 或派生表固化分组结果
把部门级统计（如平均薪资、最高薪资）提前算好，再和主表 JOIN 或用 EXISTS 关联。这样每组只算一次，且可加索引加速关联。
示例：查「所在部门平均薪资 > 10000 且本人是该部门薪资最高者」的员工：
WITH dept_stats AS ( SELECT dept, AVG(salary) AS avg_sal, MAX(salary) AS max_sal FROM emp GROUP BY dept HAVING AVG(salary) > 10000 ) SELECT e.* FROM emp e JOIN dept_stats d ON e.dept = d.dept AND e.salary = d.max_sal;
-
dept_stats是一次性计算，HAVING过滤掉低薪部门，避免后续无效 JOIN -
JOIN条件同时匹配部门和最高薪资，比EXISTS更直观；若需用EXISTS（比如主表有大量 NULL dept），改写为：EXISTS (SELECT 1 FROM dept_stats d WHERE d.dept = e.dept AND d.max_sal = e.salary) - 确保
emp(dept, salary)有联合索引，否则JOIN可能回表严重
当必须用 EXISTS + GROUP BY 时，只在外层做群组存在性判断
典型场景：查「至少有两个订单、且最近一笔订单在 7 天内」的用户。这里 GROUP BY 是子查询内部的，EXISTS 只负责“是否存在满足条件的群组”，不参与聚合逻辑。
SELECT * FROM users u
WHERE EXISTS (
SELECT 1 FROM orders o
WHERE o.user_id = u.id
GROUP BY o.user_id
HAVING COUNT(*) >= 2
AND MAX(o.created_at) >= CURRENT_DATE - INTERVAL '7 days'
);- 子查询里
GROUP BY o.user_id是自包含的，不依赖外层字段值（除了WHERE关联） -
HAVING中的COUNT(*)和MAX()都是针对该用户的订单群组，语义清晰 - 性能关键：
orders(user_id, created_at)必须有联合索引，否则GROUP BY+HAVING会全表扫描 - 注意：PostgreSQL 要求
SELECT列必须出现在GROUP BY中，所以写SELECT 1是安全的；MySQL 8.0+ 同理
最容易被忽略的是：GROUP BY 分组时，所有 NULL 值会被归为同一组。如果 dept 字段允许 NULL，又没在 HAVING 里显式排除，那个“NULL 部门组”的聚合结果可能悄悄污染你的业务判断。
