COUNT(DISTINCT user_id)不准主因是未过滤无效ID、未处理空格及时区偏差；需加WHERE过滤NULL/空值/匿名ID，用TRIM()清洗，以本地时区对齐日期，并在大数据量下考虑近似统计。
为什么 COUNT(DISTINCT user_id) 有时不准
直接写 COUNT(DISTINCT user_id) 看似简单，但实际常漏掉「活跃」的定义边界。比如：用户当天登录了 5 次，COUNT(DISTINCT user_id) 只算 1 人，这没错；但如果表里混着测试账号、系统埋点失败产生的空 user_id 或匿名 ID（如 'anonymous_123'），它们也会被计入——结果虚高。
- 务必先过滤掉无效值：
WHERE user_id IS NOT NULL AND user_id != '' AND user_id NOT LIKE 'anonymous%' - 注意字段类型：如果
user_id是字符串但含前后空格，'abc '和'abc'会被判为不同值，建议加TRIM(user_id) - 某些数据库（如旧版 Hive）对
DISTINCT的 NULL 处理不一致，显式排除更稳妥
在时间窗口内统计要小心时区和粒度
「活跃用户数」默认指「日活」，但 SQL 里没内置「今天」概念，全靠你写对时间条件。用错会导致跨天重复或漏计。
- 别直接写
WHERE event_time >= '2024-06-01'——这是 UTC 时间，而业务通常按本地时区（如东八区）算日活 - 推荐方式：用数据库时区函数对齐，例如 PostgreSQL 用
event_time AT TIME ZONE 'Asia/Shanghai'::date = CURRENT_DATE - 如果原始字段是字符串（如
'2024-06-01 14:23:05'），先转成时间再时区转换，避免字符串截取（SUBSTR(event_time, 1, 10)）误伤夏令时或格式不统一的数据
COUNT(DISTINCT) 在大数据量下很慢，怎么破
当用户行为表超亿级，COUNT(DISTINCT user_id) 会触发全局去重，Shuffle 开销大，容易 OOM 或超时。不是不能用，而是得看场景换策略。
- 近似统计可接受时，用
APPROX_COUNT_DISTINCT(user_id)（BigQuery / Spark SQL 支持），误差率通常 - 有用户分桶标识（如
user_id % 100）且允许分天预聚合，可先按桶 + 日期 GROUP BY 去重，再二次汇总 - MySQL 8.0+ 或 ClickHouse 等引擎支持
HLL（HyperLogLog）类型，建表时存聚合状态，查时直接HLL_UNION_AGG(hll_col)，适合实时看板
JOIN 后再 COUNT(DISTINCT) 容易多算
常见错误：为补全用户属性，LEFT JOIN 用户维表，结果发现日活数字比单表还大。这是因为一个用户在事实表只有一条记录，但维表里可能有多个匹配行（如多地址、多标签），导致笛卡尔膨胀。
- 必须把
COUNT(DISTINCT)放在 JOIN 前完成，或确保 JOIN 条件唯一（如只连主地址、用ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY updated_at DESC) = 1先去重维表） - 验证方法：单独跑
SELECT COUNT(DISTINCT user_id) FROM fact_table WHERE ...，再对比 JOIN 后结果，差值明显就说明膨胀了 - ClickHouse 等列存库支持
JOIN ON子句中用子查询预聚合，能规避这个问题
真正难的从来不是写对那一行 COUNT(DISTINCT)，而是搞清「谁算活跃」「按谁的时间」「数据干净吗」「下游怎么用」——这些不会报错，但会让数字失去业务意义。
