SQL如何统计分组内不重复值的占比_结合COUNT DISTINCT计算

SQL如何统计分组内不重复值的占比：结合COUNT DISTINCT计算

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

GROUP BY 后怎么算每个分组里某字段去重后的占比

直接拿 COUNT(DISTINCT ...) 除以总行数，这个思路没错，但分母用错了地方——分母必须是当前分组的总行数，而不是整张表。正确的姿势是，分子用 COUNT(DISTINCT b)，分母用 COUNT(*)，并且两者都必须在同一个 GROUP BY 分组内计算。

一个看似合理却可能踩坑的写法是：SELECT a, COUNT(DISTINCT b)/COUNT(*) FROM t GROUP BY a。在某些数据库（比如旧版MySQL）的严格模式下，它可能报错；更隐蔽的风险在于，如果字段 b 存在 NULL 值，COUNT(DISTINCT b) 会忽略它们，而 COUNT(*) 却不会，这个差异如果不留意，结果就可能失真。

• 分母固定用 COUNT(*)：除非你明确想排除 b 为 NULL 的行，否则别用 COUNT(b)。
• 分子支持度良好：COUNT(DISTINCT b) 在 PostgreSQL、SQL Server、MySQL 5.7+、BigQuery、Trino 等主流引擎中都没问题，但 SQLite 需要 3.25 及以上版本。
• 先统一口径再统计：如果字段是字符串且可能存在空格或大小写不一致，统计前最好用 TRIM(UPPER(b)) 处理一下，否则“北京”和“北京 ”会被算作两个值，导致占比虚高。

正确做法是分子用COUNT(DISTINCT b)、分母用COUNT(*)，二者均在GROUP BY同一分组内计算；需注意NULL处理、数据库兼容性及大数据量下的近似计算优化。

如何避免 NULL 干扰占比计算

COUNT(DISTINCT ...) 天生就会跳过 NULL，这通常是好事。但有些业务场景下，NULL 本身代表一种状态（比如“未填写”），你需要把它也当作一个独立的值来统计。这时候，原生的 DISTINCT 就不够用了，得手动处理。

举个例子：用户表的 country 字段有很多 NULL，你想分别计算“明确填写了国家”和“完全没填”的用户各占多少比例。

• 将 NULL 显式转化：可以用 COUNT(DISTINCT COALESCE(country, 'NULL'))，把 NULL 转成一个特定的字符串标记。
• 单独计算 NULL 占比：如果只想看 NULL 的比例，A VG(CASE WHEN country IS NULL THEN 1.0 ELSE 0.0 END) 这种写法意图更清晰。
• 注意标记冲突：用 COALESCE(country, 'NULL') 时，要确保你选的标记（如‘NULL’）不会与实际数据中的合法值（万一真有叫“NULL”的国家？）冲突。保险起见，可以用‘’这类业务中不可能出现的字符串。

大数据量下 COUNT(DISTINCT) 性能很慢怎么办

在亿级数据表上，对高基数字段（比如 user_id）做精确的 COUNT(DISTINCT)，很容易引发磁盘溢出（spill）甚至内存不足（OOM），在 Presto/Trino 或旧版 Hive 上尤其明显。

• 首选近似计算：如果业务能接受微小误差，使用 APPROX_COUNT_DISTINCT(user_id)（BigQuery、Trino、Spark SQL 等支持）是性能提升的最快路径，误差通常能控制在 2% 以内。
• 利用业务规律分步聚合：如果字段本身有分区规律（比如按天分区），可以先按 date, user_id 分组做一层去重，再在外层按 date 统计，这样能大幅减少单次 DISTINCT 操作需要处理的数据量。
• 过滤前置原则：务必先通过 WHERE 条件（如 WHERE status = 'active'）过滤掉不需要的数据，再进行分组聚合，避免在全集上做昂贵的去重操作。

跨数据库兼容写法要注意什么

标准 SQL 的 COUNT(DISTINCT x) 语法兼容性看起来不错，但魔鬼藏在细节里：

• Oracle 12c 之前有限制：不支持直接在 COUNT(DISTINCT ...) 中与 GROUP BY 混用某些列，通常需要套一层子查询来绕过。
• SQL Server 的语法敏感度：COUNT(DISTINCT x) 是合法的，但 SUM(DISTINCT x) 就不行，需要注意不同聚合函数对 DISTINCT 的支持情况。
• MySQL 的严格模式：当开启 ONLY_FULL_GROUP_BY 时，SELECT 列表中的每一列，都必须出现在 GROUP BY 子句中，或者被聚合函数包裹，别漏掉那些非分组的字段。
• PostgreSQL 的“智能”推断：较新版本（9.1+）允许 SELECT 中间出现某些非分组字段（基于函数依赖检测），但最好不要依赖这种特性，保持写法严格兼容更稳妥。

说到底，最保险的写法永远是：所有未参与聚合的字段都明确列在 GROUP BY 子句中，所有聚合表达式都完整写出，不要寄希望于数据库引擎去自动推断你的意图。