在SQL中，COUNT(DISTINCT user_id)是去重并计数的标准写法，它会忽略NULL值。而COUNT(*)配合GROUP BY或者遗漏DISTINCT等写法都是错误的。NULL值默认不会被计入统计，如果需要处理，可以使用COALESCE函数。COUNT(DISTINCT user_id)的性能瓶颈主要来自于全表扫描和哈希去重操作，因此可以通过添加索引、时间范围过滤以及避免在列上进行函数操作等方式来优化查询性能。

直接用 COUNT(DISTINCT user_id) 就行

这是最标准、最通用的写法，所有主流数据库（MySQL 5.7+、PostgreSQL、SQL Server、Oracle、SQLite）都支持。它会先对 user_id 值去重（把重复值和 NULL 都筛掉），再计数，一步到位。

常见错误是写成 COUNT(*) 配合 GROUP BY user_id，结果返回的是多行（每用户一行），不是总数；或者漏掉 DISTINCT，直接算所有记录数——这统计的是订单数/行为数，不是用户数。

• 确保 user_id 能唯一标识用户（比如别用 name 或 email，它们可能重复或变更）
• NULL 值默认不计入——如果“未登录用户”用 NULL 表示，它们会被完全忽略
• 想把 NULL 当作一类用户计入，得改写为 COUNT(DISTINCT COALESCE(user_id, -1))（前提是 -1 不是真实用户 ID）

COUNT(DISTINCT) 慢或超时，大概率是数据量或执行方式问题

不是语法错了，而是底层要全表扫描 + 构建哈希表去重。千万级表上很容易卡住，尤其内存不足时会落盘排序，I/O 成瓶颈。

优化方向不是换写法，而是控制输入规模和加速访问路径：

• 加复合索引：CREATE INDEX idx_status_user ON events (status, user_id)（如果常带状态过滤）
• 永远带上时间范围：WHERE event_time >= '2024-06-01'，别扫全表
• 避免在 WHERE 里对 user_id 用函数，比如 WHERE UPPER(user_id) = 'ABC'——索引失效，连带拖慢整个 COUNT(DISTINCT)
• 真要近似值：PostgreSQL 用 APPROX_COUNT_DISTINCT(user_id)，ClickHouse 用 uniq(user_id)，误差通常 < 1%，快一个数量级

按天/按维度分组统计时，NULL 和时区最容易翻车

写成 SELECT DATE(event_time), COUNT(DISTINCT user_id) FROM events GROUP BY DATE(event_time) 看似没问题，但实际常出偏差。

两个关键陷阱：

• 时区错位：event_time 是 UTC 存储，但 DATE(event_time) 按数据库服务器时区解析，可能把北京时间 6 月 1 日 00:30 的行为归到 UTC 的 5 月 31 日——建议统一转时区：DATE(event_time AT TIME ZONE 'Asia/Shanghai')
• NULL 放大效应：某天所有 user_id 都是 NULL，该日结果返回 0 而非 NULL，后续做环比时容易误判为“零活跃”，而不是“数据缺失”
• 空字符串 '' 和 NULL 是不同值——查一下 SELECT COUNT(*) FROM t WHERE user_id = '' OR user_id IS NULL，确认是否混入脏数据

需要累计去重数？别硬套窗口函数

COUNT(DISTINCT user_id) OVER (ORDER BY event_time) 在所有主流数据库都会报错，因为聚合函数不能嵌套窗口函数。

PostgreSQL 可用 array_agg + unnest + cardinality 模拟，但窗口越大性能越差，且不处理 NULL；MySQL 8+ 几乎没靠谱原生方案。

• 真正可行的路只有两条：用应用层维护累计状态，或预计算每日 UV 再做前缀和
• 临时表或物化视图存每日 COUNT(DISTINCT user_id) 结果，查累计值时只扫小表
• 别在实时查询里拼数组、去重、再计数——那不是 SQL 该干的活

实际最难的从来不是敲出那行 COUNT(DISTINCT user_id)，而是搞清 user_id 字段里到底有没有 NULL、空字符串、重复映射，以及你的查询跑在什么引擎上、走的是哈希还是排序去重——这些不看执行计划，光靠语法猜不出来。