因为WHERE执行在聚合之前，COUNT()等聚合函数尚未计算，数据库会报错；正确做法是用HAVING配合GROUP BY筛选分组后的低频值，如HAVING COUNT(*) >= 5。
为什么不能直接在 WHERE 中用 COUNT() 过滤低频值
因为 WHERE 执行在聚合之前，而 COUNT() 是聚合函数，此时还没分组，SQL 会报错 ERROR: aggregate functions are not allowed in WHERE。想筛掉出现少于 N 次的 user_id，得先分组统计频次，再基于结果过滤——这正是 HAVING 的职责。
用 HAVING 在 GROUP BY 后筛低频键值
典型场景：计算每个高频用户的平均订单金额，但只保留出现 ≥5 次的 user_id。注意两点：一是 HAVING 必须跟在 GROUP BY 后；二是它能引用聚合表达式，但不能用别名（除非数据库支持，如 PostgreSQL 9.6+）。
示例：
SELECT user_id, AVG(order_amount) AS avg_amount FROM orders GROUP BY user_id HAVING COUNT(*) >= 5;
常见错误：
- 把
COUNT(*) >= 5写进WHERE→ 报错 - 在
HAVING中写AVG(order_amount) > 100却没在SELECT或GROUP BY中包含该字段 → 部分数据库（如 MySQL 5.7 严格模式）会拒绝执行
需要多层聚合时：用子查询或 CTE 先降维
如果“低频过滤”和“高精度聚合”逻辑复杂（比如要先按天归因、再筛用户、最后算加权平均），HAVING 就不够用了。这时必须拆成两步：第一步产出带频次标记的中间结果，第二步在此基础上聚合。
推荐用 CTE 提升可读性（兼容 PostgreSQL / SQL Server / BigQuery / DuckDB）：
WITH user_freq AS ( SELECT user_id, COUNT(*) AS freq FROM orders GROUP BY user_id ), high_freq_orders AS ( SELECT o.* FROM orders o INNER JOIN user_freq u ON o.user_id = u.user_id WHERE u.freq >= 5 ) SELECT COUNT(*) AS total_orders, SUM(order_amount) / SUM(item_count) AS avg_amount_per_item FROM high_freq_orders;
关键点：
- 子查询里别名（如
user_freq）不能在外部WHERE中直接引用聚合列，必须显式JOIN或IN - 若数据量大，确保
user_id有索引，否则JOIN性能可能骤降 - BigQuery 等引擎对 CTE 有物化控制（
MATERIALIZED），不加可能重复计算子查询
精度陷阱：COUNT(DISTINCT) 和浮点聚合的取舍
“高精度聚合”常被误解为“用 DECIMAL 类型”，其实更常踩坑的是语义精度。比如用 COUNT(DISTINCT user_id) 统计去重数，在海量数据下可能因近似算法（如 HyperLogLog）返回估算值——PostgreSQL 默认精确，但 Redshift / Spark SQL 默认启用近似。
确认方式：
- 查执行计划是否含
approx_count_distinct或类似字样 - Redshift 中显式写
APPROXIMATE COUNT(DISTINCT user_id)才启用近似；默认是精确的 - 浮点聚合如
AVG()在不同引擎中舍入策略不同（如 DuckDB 默认 round-half-to-even），若需严格一致，改用SUM(x)/COUNT(*)并转DECIMAL
真正影响结果可信度的，往往不是语法写法，而是没意识到底层聚合是否可复现、是否跨平台一致。
