SQL查询WHERE引用字段别名报错 非HAVING的替代实现方案

SQL实际执行顺序和书写顺序不一致，WHERE子句执行阶段远早于SELECT段的字段别名计算，标准执行顺序大致为：
FROM/JOIN关联 → WHERE行级过滤 → GROUP BY分组 → 聚合函数计算 → HAVING聚合后过滤 → SELECT计算别名、输出字段 → ORDER BY排序 → LIMIT截断
你在WHERE里引用的unreviewed_records是SELECT阶段才会生成的聚合计算别名，执行到WHERE时这个字段还没被计算，自然会报字段不存在的错误。

关于HAVING性能的常见误区 #

你担心HAVING带来额外性能损耗是完全没必要的：你要筛选的是聚合计算后的结果，这类过滤本来就必须等聚合动作完成后才能执行，不管用什么写法，执行时机和HAVING完全一致，不存在额外开销。
网传HAVING性能差的场景，是指开发者错误把本该放在WHERE里、针对原始表行的过滤条件写到HAVING中，导致数据库做完全量聚合后才过滤，浪费计算资源；但你的筛选条件本身就是基于SUM()聚合结果的，用HAVING是标准合规的写法，没有任何性能问题。

推荐修复方案（最简便，无额外开销） #

直接把末尾的where关键字替换为having即可，不需要改动核心计算逻辑，同时顺手修正原SQL里多余的尾逗号语法问题，修正后的完整代码如下：

select 
    r_alias.serv_id, 
    r_alias.node_id,
    SUM(g_alias.total_records) - SUM(r_alias.reviewed_records) AS unreviewed_records,
    SUM(r_alias.reviewed_records) AS reviewed_records,
    SUM(g_alias.total_records) AS total_records
FROM (
    SELECT 
        prs.serv_id,
        prs.node_id,
        SUM(prs.reviewed_records) AS reviewed_records
    FROM p_rev_server prs
    WHERE
        prs.area_id = 3
        AND prs.subId = 3
        AND prs.sId = 12
    GROUP BY prs.serv_id, prs.node_id, prs.domain_name
) r_alias
INNER JOIN (
    SELECT
        serv_id,
        node_id,
        SUM(pgs.total_records) AS total_records
    FROM p_gen_serve pgs
    WHERE 
        pgs.area_id = 3
        AND pgs.subId = 3
        AND pgs.sId = 12
        AND pgs.total_records > 0
    GROUP BY pgs.serv_id, pgs.node_id, pgs.domain_name
) g_alias
ON g_alias.serv_id = r_alias.serv_id AND g_alias.node_id = r_alias.node_id
LEFT JOIN p_cust_columns cust_cols
ON cust_cols.node_id = r_alias.node_id AND cust_cols.serv_id = r_alias.serv_id
GROUP BY r_alias.serv_id, r_alias.node_id
HAVING unreviewed_records = 5
ORDER BY g_alias.node_id ASC
LIMIT 25

补充说明：

1. 原WHERE条件里的NOT (unreviewed_records IS NULL)是冗余的：SQL里NULL和任何值做等值判断结果都是未知，会被直接过滤，因此unreviewed_records = 5本身就会自动排除NULL值，不需要额外判断。
2. 你写的LEFT JOIN p_cust_columns cust_cols没有引用该表的任何字段，属于多余关联，如果没有额外的筛选/取值需求可以直接删掉，能减少关联计算开销。

其他可选方案（无性能优势，仅作参考） #

• 子查询/CTE包裹方案：把带聚合计算的逻辑包成一层内层查询，外层再用WHERE筛选内层生成的别名，执行效果和HAVING完全一致，但会增加SQL嵌套层级，可读性更差，没有特殊需求不推荐使用。
• WHERE重复写表达式方案：仅适用于别名是非聚合的普通行级计算的场景，你的场景里别名是跨表聚合结果，直接把聚合表达式写在WHERE里会触发“聚合函数不能在WHERE中使用”的语法错误，完全不可行。
• 物理表计算列方案：计算列是表层面提前定义的持久化字段，仅适合单表固定逻辑的计算，你这个是跨表动态聚合的结果，根本不适用，没必要折腾。

内容的提问来源于stack exchange，提问作者SamAko