统计每个分组下究竟有多少不同的用户——这个问题，几乎所有做数据分析的开发者都会遇到。解法其实不复杂，但坑确实不少，下面我们一条条掰开来说。
先说核心结论：GROUP BY + COUNT(DISTINCT user_id) 是标准解法，主流数据库全支持，这是最扎实、最正统的写法。
最直接的解法：GROUP BY + COUNT(DISTINCT user_id)
去重计数，核心就是COUNT(DISTINCT column)。MySQL、PostgreSQL、SQL Server（2017+）、Oracle 都支持这个语法，这也是业内公认的标准写法。
新手容易踩的坑是什么呢？
- 写成
COUNT(user_id)或COUNT(*)—— 这会把所有行都算进去，包括重复的用户，计数就完全不对了。 - 还有人试
SELECT DISTINCT user_id FROM ... GROUP BY group_col，结果根本没法聚合出每组的数量，因为DISTINCT是对整个结果集去重，不是分组去重。
几个需要留意的细节：
COUNT(DISTINCT user_id)必须搭配GROUP BY使用，否则语法报错或语义完全错误。user_id如果为空（NULL），COUNT(DISTINCT)会自动忽略它。这通常符合预期，但得确认业务逻辑——如果业务上把NULL当作“未登录用户”并需要统计在内，那就要另做处理。- 大数据量场景下，
DISTINCT可能会触发临时表或文件排序，执行计划里重点关注Using temporary; Using filesort，这往往是性能瓶颈。
SELECT category, COUNT(DISTINCT user_id) AS unique_user_count FROM orders GROUP BY category;
SQL Server 旧版本的兼容方案
SQL Server 2016 及更早版本其实支持COUNT(DISTINCT)在普通聚合中使用，真正不支持的是极老的版本（比如2005）。如果遇到“不支持DISTINCT”的报错，大概率是语法写错了，或者误用了子查询结构。
但万一真遇到受限的环境——比如对接遗留系统或某些嵌入式数据库——可以用子查询去重后再计数：
- 先
SELECT DISTINCT group_col, user_id，外层再按group_col计数。 - 性能上就有点吃亏了，尤其是当
user_id重复率特别高的时候，中间结果集可能膨胀得让人头疼。 - 注意：
WHERE过滤条件必须放在内层子查询里，否则逻辑会出错。
SELECT category, COUNT(*) AS unique_user_count FROM ( SELECT DISTINCT category, user_id FROM orders WHERE status = 'completed' -- 过滤必须放这里 ) AS deduped GROUP BY category;
NULL 用户 ID 的处理要主动判断
COUNT(DISTINCT user_id) 天然忽略 NULL，这没问题。但有些业务场景下，“未登录用户”是用 NULL 表示的，你可能需要把它也算作一类独立用户。
处理方式有好几种：
- 用
COUNT(DISTINCT COALESCE(user_id, -1))把NULL映射为固定值（比如-1），前提是user_id本身不会取到-1。 - 更稳妥的方式是条件聚合：
COUNT(DISTINCT CASE WHEN user_id IS NULL THEN 'anonymous' ELSE CAST(user_id AS VARCHAR) END)。 - 尽量避免直接用
ISNULL(user_id, 0)—— 如果user_id是字符串类型，类型转换可能会报错。
GROUP BY 字段与 SELECT 中非聚合字段必须严格一致
这是初学者高频翻车点：只写了 GROUP BY category，却在 SELECT 里多加了 region。MySQL 5.7+ 和 PostgreSQL 会直接报错：ERROR 1055 或 ERROR: column "region" must appear in the GROUP BY clause。
所以：
- 检查
SELECT列表：所有非聚合字段（即没套COUNT、SUM等函数的）必须出现在GROUP BY中。 - 别依赖 MySQL 的
sql_mode=only_full_group_by关闭状态——关了只是“不报错”，结果不可靠。 - 如果想按多个维度分组（比如按
category和region），GROUP BY必须写全：GROUP BY category, region。
实际跑起来前，先 EXPLAIN 看看执行计划，重点盯住 key 是否命中索引，以及有没有 Using temporary。去重计数在千万级表上很容易成为瓶颈，语法写对只是第一步，性能优化才是真正的硬仗。
