会。标准sql中having不支持直接嵌套非标量子查询，因其要求标量值而子查询可能返回多行，导致语义冲突；正确写法包括标量子查询、exists及with预计算。
HAVING 里直接写子查询会报错吗？
会。标准 SQL（包括 MySQL 8.0+、PostgreSQL、SQL Server）中，HAVING 子句允许使用聚合函数和分组字段，但**不支持在 HAVING 中直接嵌套非标量子查询**（比如返回多行或多列的子查询）。常见错误是：ERROR 1140: Mixing of GROUP columns... with no GROUP columns is illegal 或 Subquery returns more than 1 row。
为什么不能直接用？根本限制在哪？
HAVING 是在 GROUP BY 之后执行的，它对每个分组做一次判断。而子查询如果没加限制（如 LIMIT 1 或聚合），很可能返回多行——这会让 SQL 引擎无法把结果跟当前分组对齐。本质是语义冲突：分组上下文要求标量值（单个 true/false 或数值），子查询却可能提供集合。
- MySQL 5.7 默认严格模式下，
HAVING中子查询若未显式聚合或限制，直接报错 - PostgreSQL 更严格：不允许子查询出现在
HAVING中，除非用EXISTS或标量子查询（带SELECT COUNT(*)这类聚合） - 即使“侥幸”运行成功（如某些 MySQL 兼容模式），结果也常不可靠——子查询可能被当作对整个结果集求值，而非按分组求值
真正能用的三种写法（附场景和注意点）
不是不能用，而是得绕开语法陷阱。核心思路：把子查询变成标量，或移到更安全的位置。
MySQL（Linux）
下载
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
-
用标量子查询（必须只返回 1 行 1 列）：比如
HAVING AVG(sales) > (SELECT AVG(sales) FROM orders)—— 注意括号内必须是聚合或带LIMIT 1的单值查询 -
用
EXISTS检查分组是否存在关联记录：例如HAVING EXISTS (SELECT 1 FROM users u WHERE u.dept_id = dept.id)，这里dept.id是外部分组字段，子查询依赖于当前分组，安全 -
把子查询提前到
FROM或WITH中预计算：更推荐。例如先用WITH avg_all AS (SELECT AVG(sales) AS global_avg FROM orders)，再在HAVING中引用global_avg字段
容易踩坑的典型误写
这些看着像能跑，实际要么报错，要么逻辑错：
-
HAVING COUNT(*) > (SELECT COUNT(*) FROM logs WHERE user_id = users.id)—— 错！users.id在HAVING中不可见（除非是分组字段且别名明确） -
HAVING product_id IN (SELECT top_product FROM bestsellers)—— 错！IN要求子查询返回单列，且若bestsellers表为空，整个HAVING变成FALSE，所有分组被过滤掉 - 在 MySQL 中用
HAVING (SELECT ...)不加聚合，依赖旧版本隐式转换 —— 错！升级后立刻失效，且结果不稳定
复杂点在于：子查询是否依赖当前分组、是否可标量化、以及数据库版本对 SQL 标准的遵守程度。别指望“试出来就能用”，先确认执行计划里子查询是否真的按分组执行了——最稳妥的方式，永远是把子查询拆到 WITH 或 JOIN 里。
