结论：COUNT(DISTINCT)不能在同一GROUP BY中直接并列统计多个字段的独立去重数，必须用子查询或CTE拆分；否则因分组上下文共享、NULL处理不一致及数据库兼容性差异，易致结果错误或报错。
直接说结论：COUNT(DISTINCT ...) 不能在同一个聚合层级里“嵌套”出多个独立去重计数，必须用子查询或 CTE 拆开；否则会因分组粒度冲突、NULL 处理不一致或数据库优化器误判导致结果错误或报错。
为什么不能直接写多个 COUNT(DISTINCT) 在同一 GROUP BY 中？
表面看语法合法，但实际隐含陷阱：
-
COUNT(DISTINCT user_id)和COUNT(DISTINCT order_id)的去重逻辑互不干扰，但若其中一列存在大量 NULL（比如order_id在退款单里为空），不同数据库对COUNT(DISTINCT NULL)的处理不一致：PostgreSQL 忽略 NULL，MySQL 5.7+ 也忽略，但旧版 Hive 可能报错或返回 0 - 当你要算「每个省份的独立用户数 + 独立订单数 + 独立商品 SKU 数」时，三者去重范围本应完全独立，但若共用
GROUP BY province，数据库不会为你自动隔离计算上下文——它只是并行执行三个函数，看似没问题，实则无法验证中间去重集合是否被意外截断（尤其涉及 JOIN 后膨胀） - 更隐蔽的问题：如果外层还带
HAVING或WHERE过滤，某些引擎（如 PrestoSQL）会在去重前就裁剪数据，导致COUNT(DISTINCT)结果偏低且难以复现
正确做法：用子查询分别算，再 JOIN 对齐
确保每个 COUNT(DISTINCT) 在自己干净的上下文中运行，避免相互污染：
SELECT t1.province, t1.user_cnt, t2.order_cnt, t3.sku_cnt FROM ( SELECT province, COUNT(DISTINCT user_id) AS user_cnt FROM orders WHERE status = 'paid' GROUP BY province ) t1 JOIN ( SELECT province, COUNT(DISTINCT order_id) AS order_cnt FROM orders WHERE status = 'paid' GROUP BY province ) t2 ON t1.province = t2.province JOIN ( SELECT province, COUNT(DISTINCT sku_id) AS sku_cnt FROM order_items GROUP BY province ) t3 ON t1.province = t3.province;
- 每个子查询只聚焦一个指标，
WHERE条件可独立控制，NULL 自动被COUNT(DISTINCT)忽略 - 必须显式给每个子查询加别名（
t1/t2/t3），否则 PostgreSQL/MySQL 8.0+ 报subquery in FROM must have an alias - 注意
JOIN会丢掉某个维度为空的省份（比如某省无订单但有用户），如需保留，改用FULL OUTER JOIN或统一用 CTE +LEFT JOIN
更稳的替代：CTE 预聚合 + 单次扫描
当所有指标都基于同一张事实表（如 orders），用 CTE 提前做一次宽表聚合，比多次子查询更高效：
WITH base AS (
SELECT
province,
user_id,
order_id,
NULL AS sku_id -- 占位，保持列对齐
FROM orders
WHERE status = 'paid'
UNION ALL
SELECT
province,
NULL AS user_id,
NULL AS order_id,
sku_id
FROM order_items
)
SELECT
province,
COUNT(DISTINCT user_id) AS user_cnt,
COUNT(DISTINCT order_id) AS order_cnt,
COUNT(DISTINCT sku_id) AS sku_cnt
FROM base
GROUP BY province;- 避免重复扫描源表，尤其适合大表；
UNION ALL不去重，性能优于UNION -
NULL占位是关键：让所有指标共享同一分组上下文，COUNT(DISTINCT)各自过滤自己的非空值 - 此法在 Hive/Spark SQL 中稳定，在 PostgreSQL 中需确认
UNION ALL后能否正确识别各列类型（必要时加::text显式转换）
容易被忽略的兼容性坑
不是所有数据库都把 COUNT(DISTINCT) 当成一级公民：
- MySQL 5.7 不支持在子查询中对派生表用
COUNT(DISTINCT)做外层聚合，会报Invalid use of group function；必须升级到 8.0+ 或改用临时表 - Hive 3.x 默认开启
hive.optimize.distinct.rewrite，会自动把多个COUNT(DISTINCT)拆成 MapReduce 多轮任务，但若字段基数极高（如亿级user_id），可能 OOM；此时得关掉该优化，手动用GROUP BY+COLLECT_SET模拟 - SQLite 不支持
COUNT(DISTINCT)多字段写法（COUNT(DISTINCT a, b)非法），只能单字段去重，多维去重要靠子查询
真正难的不是写出语法，而是判断哪一层该去重、哪些 NULL 是业务缺失、哪些是聚合占位——这些必须结合数据分布和业务口径人工校验，工具不会替你决定。
