COUNT(DISTINCT user_id)结果偏少主因是NULL被忽略且数据库对NULL分组行为不一致；大表性能差因需全量哈希去重，内存不足时落盘导致I/O瓶颈。
直接用 COUNT(DISTINCT user_id) 就能统计不重复用户数，但实际跑起来常发现结果偏少、耗时暴涨，甚至报错——问题往往不在函数本身，而在数据分布、NULL 处理和执行计划。
为什么 COUNT(DISTINCT) 返回的数比预期少？
最常见原因是 user_id 字段含 NULL：SQL 标准规定 DISTINCT 会忽略所有 NULL 值，不参与计数。如果业务里“未登录用户”用 NULL 表示，它们就完全不会被计入活跃用户。
- 查证方式：
SELECT COUNT(*), COUNT(user_id), COUNT(DISTINCT user_id) FROM events;—— 对比三者差值就是NULL行数 - 修复方案：按业务定义是否计入
NULL，如需计入，改写为COUNT(DISTINCT COALESCE(user_id, -1))（假设 -1 是安全占位符） - 注意：MySQL 5.7+ 和 PostgreSQL 行为一致；但某些旧版 Hive 或 Spark SQL 默认把
NULL当作一个独立值处理，结果会多算 1
COUNT(DISTINCT) 在大表上慢得离谱怎么办？
底层引擎需对全部 user_id 做哈希去重，内存不足时会落盘排序，I/O 成瓶颈。尤其当活跃用户量 > 百万且字段无索引时，单次查询可能卡住数分钟。
- 优先加索引：
CREATE INDEX idx_user_time ON events (user_id, event_time);—— 覆盖索引能避免回表，加速去重 - 限制范围：永远带上时间分区或日期条件，例如
WHERE event_time >= '2024-06-01'，别扫全表 - 替代方案：若只需近似值，PostgreSQL 可用
APPROX_COUNT_DISTINCT(user_id)，ClickHouse 直接用uniq(user_id)，误差率通常
GROUP BY 后套 COUNT(DISTINCT) 容易踩哪些坑？
比如按天统计每日活跃用户数，写成 SELECT DATE(event_time), COUNT(DISTINCT user_id) FROM events GROUP BY DATE(event_time) 看似合理，但实际可能漏掉跨天行为。
- 时区陷阱：数据库服务器时区 vs 应用时区不一致，
DATE(event_time)可能切错天（如 UTC 时间 2024-06-01 01:00 在北京时间是 6 月 1 日 09:00，但被归到 UTC 的 6 月 1 日） - 性能雪崩：GROUP BY + DISTINCT 组合会让优化器放弃索引，改用临时表分组，建议先按天预聚合再 UNION ALL
- 空值放大：如果某天所有
user_id都是NULL，该日结果返回 0 而非NULL，但后续做环比计算时容易误判为“零活跃”
真正难的不是写出这行 SQL，而是确认 user_id 的语义是否干净、时区是否对齐、以及你的引擎到底用的是哈希表还是排序去重——这些细节不查执行计划（EXPLAIN）根本看不见。
