最标准写法是count(distinct user_id)，它去重并计数，忽略null；错误写法包括count(*)配合group by或遗漏distinct；null默认不计入，需coalesce处理；性能瓶颈源于全表扫描与哈希去重，优化靠索引、时间范围过滤及避免函数操作。
直接用 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)，误差通常
按天/按维度分组统计时，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、空字符串、重复映射，以及你的查询跑在什么引擎上、走的是哈希还是排序去重——这些不看执行计划，光靠语法猜不出来。
