聚合查询默认返回一行NULL是SQL标准行为；需用EXISTS子查询判断存在性再聚合，或CTE预过滤，才能真正返回0行；须警惕BI工具外层包裹导致兜底失效。
聚合查询返回一行 NULL，不是“没数据”，而是 SQL 标准行为——只要用了 AVG、COUNT、SUM 等聚合函数，哪怕 WHERE 条件完全不匹配，也会强制输出一行（所有聚合列为 NULL）。想让它真“空”，得绕过聚合函数的默认兜底逻辑。
为什么 GROUP BY NULL 不能用
有人试过加 GROUP BY NULL 强制单行，再配合 HAVING COUNT(*) > 0 过滤。这在 MySQL 里看似能“屏蔽空结果”，但有硬伤：
- 它把所有行强行压成一组，破坏了原本的分组语义；一旦后续加条件或改逻辑，结果会悄然错位
- 在 PostgreSQL、SQL Server、Oracle 中根本无效，属于 MySQL 特有且不推荐的行为
- 执行计划里仍会扫描全表，没解决性能问题，只掩盖了语义缺陷
用 EXISTS + 子查询判断是否存在数据
真正可控的方式，是把“是否有数据”和“聚合计算”拆开：先查存在性，再决定是否执行聚合。适用于需要严格区分「无数据」和「有数据但值为 NULL」的场景，比如报表接口返回 204 No Content 或空数组。
示例（标准写法，各主流数据库兼容）：
SELECT 'data' AS status, SUM(sales) AS total FROM sales_fact WHERE region = 'CN' AND month = '2026-08' AND EXISTS ( SELECT 1 FROM sales_fact WHERE region = 'CN' AND month = '2026-08' );
关键点：
-
EXISTS子查询不返回数据，只判断逻辑真假，性能远好于COUNT(*) > 0 - 主查询的
WHERE条件必须和EXISTS内完全一致，否则可能漏判 - 如果业务允许返回空结果集（即 0 行），这个查询在无数据时就真的返回 0 行，不是一行
NULL
用 CTE 预过滤，避免聚合兜底
当必须返回结构化结果（如固定字段名、非空类型），又不想看到 NULL 值时，可先用 CTE 提取有效数据，再对 CTE 做聚合。这样聚合作用域天然被限制在非空子集上。
示例：
WITH valid_data AS ( SELECT sales, region, product_line FROM sales_fact WHERE region = 'CN' AND month = '2026-08' ) SELECT region, product_line, SUM(sales) AS total FROM valid_data GROUP BY region, product_line;
效果：
- 若
valid_data为空，整个查询返回 0 行，不会生成带NULL的占位行 - 比嵌套
IFNULL(COUNT(*), 0)更干净，不污染数值语义 - CTE 可复用，适合多指标联合计算（如同时要
SUM和AVG）
最易忽略的一点：很多 BI 工具或 ORM 会自动包裹聚合查询（例如加 SELECT * FROM (…)），导致你写的 CTE 或 EXISTS 被外层兜底逻辑覆盖。上线前务必用 EXPLAIN 或实际执行结果验证返回行数，而不是只看字段是否为 NULL。
