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 子句中，所有聚合表达式都完整写出，不要寄希望于数据库引擎去自动推断你的意图。
