不能只用distinct去重，必须先group by category, user_id统计活跃天数，再having过滤；因where在聚合前执行，无法引用count(distinct login_date)等聚合值。
用GROUP BY + HAVING筛出每个分类里活跃天数≥N的用户数
直接结论：不能只靠 DISTINCT 去重用户，必须先按分类和用户分组统计活跃天数，再用 HAVING 过滤。很多人误以为 DISTINCT user_id 配合 WHERE days_active >= N 就行——但活跃天数本身是聚合结果，没 GROUP BY 就没法算。
为什么不能在WHERE里写活跃天数条件
WHERE 执行在聚合前，无法引用 COUNT(DISTINCT login_date) 这类聚合值。常见错误写法：WHERE COUNT(DISTINCT login_date) >= 7，会直接报错 Invalid use of group function。
正确路径是：
- 先
GROUP BY category, user_id算出每人每类的活跃天数 - 再用
HAVING COUNT(DISTINCT login_date) >= 7筛出达标用户 - 最后外层再按
category统计人数（或保留明细）
完整SQL写法示例（MySQL/PostgreSQL通用）
假设表名 user_activity，字段有 category、user_id、login_date：
SELECT category, COUNT(DISTINCT user_id) AS qualified_user_count FROM ( SELECT category, user_id FROM user_activity GROUP BY category, user_id HAVING COUNT(DISTINCT login_date) >= 7 ) t GROUP BY category;
注意点：
- 内层
GROUP BY category, user_id是必须的，否则HAVING无意义 - 外层
COUNT(DISTINCT user_id)是为了防内层结果因数据重复导致多算（虽通常不会，但更稳妥） - 如果只要“每个分类下有哪些达标用户”，去掉外层聚合，直接查内层子查询即可
性能与兼容性提醒
在大数据量下，COUNT(DISTINCT login_date) 可能变慢，尤其 login_date 无索引时。建议：
- 确保
(category, user_id, login_date)有联合索引，顺序别乱 - PostgreSQL 14+ 可考虑用
APPROX_COUNT_DISTINCT替代（误差可控，快很多） - SQLite 不支持子查询里的
HAVING直接嵌套，需改用 CTE 或临时表
最易被忽略的是：业务定义的“活跃天数”是否包含时间窗口限制（比如最近30天）。若需要，记得在内层 WHERE 先过滤日期，而不是只靠 GROUP BY 和 HAVING。
