count(distinct) 不能直接加 where 或 filter，需用 count(distinct case when ... then col end) 实现条件去重，因该函数原子性导致语法不支持多层修饰，且 null 自动被忽略，确保语义正确。
COUNT(DISTINCT) 不能直接套 WHERE 或 FILTER，但可以被条件聚合替代——这是解决多维去重计数性能和语法限制的核心突破口。MySQL 8.0+、PostgreSQL、Spark SQL 都支持用 COUNT(DISTINCT CASE WHEN ... THEN col END) 实现单次扫描完成多个条件去重，避免反复扫描或子查询嵌套。
为什么不能对 COUNT(DISTINCT) 直接加 WHERE？
因为 COUNT(DISTINCT col) 是一个原子函数调用，SQL 标准不允许多层修饰：COUNT(DISTINCT col) WHERE condition 语法错误；MySQL 虽有 FILTER，但它只作用于普通聚合（如 SUM() FILTER (WHERE ...)），不支持挂载在 COUNT(DISTINCT ...) 后面。
常见错误现象包括：
- MySQL 报错
ERROR 1064 (42000): You have an error in your SQL syntax - PostgreSQL 报错
syntax error at or near "FILTER"（当尝试写COUNT(DISTINCT x) FILTER (WHERE ...)） - Spark SQL 返回空结果或全 NULL，因误用窗口函数 + DISTINCT 混合逻辑
COUNT(DISTINCT CASE WHEN ...) 是最通用写法
本质是把条件判断前移到 CASE 表达式中，让不满足条件的行返回 NULL，而 COUNT(DISTINCT ...) 天然忽略 NULL，从而实现“条件性去重”。
示例：统计每个产品线中「付费用户」和「试用用户」的去重客户数
SELECT product_line, COUNT(DISTINCT CASE WHEN status = 'paid' THEN user_id END) AS paid_users_distinct, COUNT(DISTINCT CASE WHEN status = 'trial' THEN user_id END) AS trial_users_distinct FROM orders GROUP BY product_line;
关键点：
-
CASE WHEN ... THEN user_id END中省略ELSE就等价于ELSE NULL，必须这样写，不能写ELSE ''或ELSE 0，否则会污染去重结果 - 如果想把
NULL视为有效值（极少见），需改用COALESCE(user_id, 'NULL_PLACEHOLDER')，但会破坏语义一致性，慎用 - 该写法在 MySQL 5.7+、8.0+，PostgreSQL 9.4+，Spark SQL 3.0+ 均可直接运行
多条件组合去重：用 CONCAT 或 COALESCE 拼接
当需要按多个字段联合去重（例如「同一用户在不同渠道的首次下单组合」），COUNT(DISTINCT CONCAT(user_id, '|', channel)) 是常用技巧，但要注意：
- 分隔符必须确保不与字段内容冲突，建议用罕见符号如
'\x01'或'|'+TRIM预处理 - 若任一字段为
NULL，CONCAT结果为NULL，整组会被跳过；应改用CONCAT(COALESCE(user_id, 'NULL'), '|', COALESCE(channel, 'NULL')) - 在 Spark SQL 中，
CONCAT对NULL更敏感，推荐用concat_ws('|', user_id, channel)，它自动跳过NULL参数
性能陷阱：别在大表上无索引跑 COUNT(DISTINCT)
即使改用条件聚合，底层仍需构建哈希表或排序去重，代价随数据量非线性增长。
容易被忽略的细节：
- 没有为
user_id和条件字段（如status）建联合索引时，MySQL 可能放弃使用索引，转为临时表 + filesort - Spark SQL 中，
COUNT(DISTINCT ...)默认触发 shuffle，若数据倾斜（如某个product_line占 80% 数据），task 会卡死或 OOM - 替代方案：对超大数据集，考虑用
APPROX_COUNT_DISTINCT()（Spark/BigQuery）或预计算物化视图
真正难的不是写对语法，而是判断什么时候该用精确去重、什么时候该接受近似值，以及是否值得为单个报表加索引。这些权衡往往比写一条 SQL 花的时间更多。
