COUNT(DISTINCT user_id)不准主因是NULL、空字符串、脏ID及跨系统ID格式不一致；需先过滤异常值并归一化，JOIN去重应前置子查询，时间窗口统计须用分区字段或左闭右开避免漏人。
为什么 COUNT(DISTINCT user_id) 有时不准？
不是函数本身有问题，而是数据里存在 NULL、空字符串、脏 ID（如 'unknown'、'0'）或跨系统 ID 格式不一致（比如 '123' 和 123 被当不同值）。这些都会被 COUNT(DISTINCT ...) 算作独立用户，导致虚高。
实际场景中更常见的是：埋点日志里 user_id 字段缺失时填了默认值，但没在统计前过滤；或者登录态和游客态混用，同一个自然人产生多个 ID。
建议操作：
- 先查
SELECT COUNT(*), COUNT(user_id), COUNT(DISTINCT user_id) FROM events;对比三者差距，差距大就说明有大量NULL或无效值 - 加条件过滤明显异常值：
WHERE user_id IS NOT NULL AND user_id != '' AND user_id NOT IN ('unknown', '0', 'null', 'undefined') - 若 ID 来自不同来源（如微信 OpenID + 手机号 MD5），需先做归一化映射，不能直接
DISTINCT
多表关联时去重统计容易漏掉什么？
比如想统计「过去7天完成过支付的去重用户数」，但订单表和用户表是 1:N 关系，又用了 LEFT JOIN，就可能因重复匹配把一个用户算多次——COUNT(DISTINCT) 虽能兜底，但性能差，且掩盖了 JOIN 逻辑缺陷。
更稳妥的做法是把去重逻辑提前到子查询里：
SELECT COUNT(*) FROM ( SELECT DISTINCT u.user_id FROM users u INNER JOIN orders o ON u.user_id = o.user_id WHERE o.pay_time >= CURRENT_DATE - INTERVAL '7 days' ) t;
这样既明确去重粒度，又避免大表 JOIN 后再聚合带来的内存压力。注意：如果 orders 表没有 user_id 索引，这个子查询会很慢。
时间窗口 + 去重用户，怎么避免“今天看昨天漏人”？
典型陷阱是用 WHERE event_time BETWEEN '2024-06-01' AND '2024-06-01 23:59:59' 统计单日，但数据库时区和日志打点时区不一致，或事件延迟入库（比如凌晨补发的数据落在第二天分区），就会漏掉部分用户。
安全做法是按分区字段或业务日期字段统计，并预留缓冲：
- 优先使用已清洗好的
dt分区字段（如WHERE dt = '2024-06-01'），它通常代表业务侧确认的日期 - 若必须用时间字段，用左闭右开：
WHERE event_time >= '2024-06-01' AND event_time ，避免秒级截断误差 - 对实时性要求高的场景，可额外跑一个「T+1 补偿任务」，拉取前一日未落库的延迟数据重新去重合并
大数据量下 COUNT(DISTINCT) 太慢怎么办？
在 Hive/Spark SQL 或 ClickHouse 中，COUNT(DISTINCT) 默认触发全局 shuffle，数据量超亿级时极易 OOM 或超时。这不是写法问题，是算法瓶颈。
替代方案取决于你用的引擎：
- Hive/Spark：改用
APPROX_COUNT_DISTINCT(user_id)（误差率约 2.3%），速度快 3–5 倍 - ClickHouse：用
uniq(user_id)（HyperLogLog 实现），比count(distinct)快一个数量级，且内存稳定 - 如果必须精确值且数据可分片，先按天/地域分组去重，再汇总：
SELECT COUNT(*) FROM (SELECT DISTINCT date, user_id FROM t GROUP BY date, user_id)
别为了“看起来精确”硬扛全量 COUNT(DISTINCT)，业务上是否真需要毫厘不差的数字，得先问清楚。
