WHERE子句不能用聚合函数，因执行早于分组；应改用HAVING过滤分组结果，或用子查询/窗口函数处理复杂逻辑，递归查询适配层级结构，EXPLAIN ANALYZE定位真实性能瓶颈。
WHERE 子句里不能直接用聚合函数，得用 HAVING 或子查询
很多人写 SELECT region, COUNT(*) FROM sales GROUP BY region WHERE COUNT(*) > 100，结果报错 ERROR: aggregate functions are not allowed in WHERE。这是因为 WHERE 执行在分组前，而 COUNT(*) 是分组后才有的值。
正确做法是把过滤逻辑挪到分组后：用 HAVING，或者把聚合结果当“临时表”再筛一次。
- 简单过滤分组结果 → 用
HAVING：SELECT region, COUNT(*) c FROM sales GROUP BY region HAVING c > 100 - 需要关联其他表或做多层计算 → 用子查询：
SELECT * FROM (SELECT region, COUNT(*) c FROM sales GROUP BY region) t WHERE t.c > 100 - 注意：子查询别名
t在 PostgreSQL/MySQL 8.0+ 必须有，否则报ERROR: subquery in FROM must have an alias
窗口函数比嵌套查询更稳，尤其要保留明细行时
想算每个订单的金额占所在区域总额的百分比，但又不想丢掉原始订单行——这时候硬套 GROUP BY + 子查询容易出错，比如漏了 JOIN 条件或重复聚合。
窗口函数天然支持“分组内计算但不折叠行”，语义清晰、性能通常更好。
- 错误写法（易漏关联键）：
SELECT s.*, t.region_total FROM sales s JOIN (SELECT region, SUM(amount) region_total FROM sales GROUP BY region) t ON s.region = t.region—— 如果region为空，JOIN会丢数据 - 推荐写法：
SELECT *, SUM(amount) OVER (PARTITION BY region) AS region_total, amount / SUM(amount) OVER (PARTITION BY region) AS pct FROM sales -
PARTITION BY和GROUP BY逻辑类似，但不会改变行数；空值默认被归为同一组，如需排除，加WHERE region IS NOT NULL
WITH 递归查询处理层级关系，避免手写 N 层子查询
查某个部门下所有子部门的累计销售额，如果组织树深度不确定，硬写 JOIN 自身 3 次、4 次，既难维护又容易漏层级。
用 WITH RECURSIVE 把“找子节点”这个动作抽象成迭代过程，SQL 更贴近业务意图。
- 基础结构：
WITH RECURSIVE dept_tree AS (SELECT id, name, parent_id, sales_amt FROM departments WHERE id = 123 UNION ALL SELECT d.id, d.name, d.parent_id, d.sales_amt FROM departments d INNER JOIN dept_tree dt ON d.parent_id = dt.id) - 关键点：
UNION ALL前是“起点”，后是“怎么往下找”；必须有终止条件（比如parent_id IS NULL或层级限制），否则可能无限循环 - PostgreSQL 支持
MAX_RECURSION_DEPTH配置，MySQL 8.0+ 需靠cte_max_recursion_depth系统变量控制
EXPLAIN ANALYZE 看执行计划，别猜哪层子查询拖慢了
嵌套深了，一跑十几秒，很多人第一反应是“是不是子查询太多”，其实瓶颈常在最外层的 JOIN 或缺失索引上。
直接看 EXPLAIN ANALYZE 输出，重点关注 Rows Removed by Filter 和 Actual Total Time 最高的节点。
- 如果某层子查询的
Actual Rows是百万级，但外层只取 10 行，说明没下推过滤条件 —— 检查是否能把WHERE提前，或加索引覆盖WHERE + GROUP BY字段 - 看到
Nested Loop且内表没走索引，大概率是JOIN条件字段没索引，或者类型隐式转换（比如varchar和text比较） - MySQL 的
EXPLAIN FORMAT=JSON能看到更细的物化（materialized）信息，PostgreSQL 则留意CTE Scan是否被多次执行
嵌套本身不慢，慢的是没让数据库提前剪枝。真正卡住的地方，往往不在你怀疑的那一层。
