必须将CASE嵌套在聚合函数或GROUP BY中使用，因其仅为表达式而非分组语句；典型做法是先用SUM(CASE...)或COUNT(*) FILTER(...)计算用户活跃次数，再在外层SELECT中用CASE分级，并注意NULL处理、边界定义及跨库兼容性。
怎么用 CASE 配合聚合函数给用户打活跃等级
直接结论：不能只写 CASE，必须套在 GROUP BY 或聚合函数（如 COUNT、SUM）里，否则会报错或逻辑错乱。常见错误是把 CASE 当成独立分组语句，其实它只是表达式，不产生分组能力。
典型场景：你有一张 user_behavior 表，字段含 user_id、event_time、event_type，想按近30天登录次数把用户分为「高活」「中活」「低活」「沉默」四档，并统计每档人数。
实操建议：
- 先用子查询或 CTE 算出每个用户的活跃次数（比如
COUNT(*) FILTER (WHERE event_type = 'login')或SUM(CASE WHEN event_type='login' THEN 1 ELSE 0 END)），再在外层用CASE分级 - 分级逻辑必须写在
SELECT中，不能放GROUP BY后面直接分组——GROUP BY只能对原始列或确定表达式分组，而活跃等级依赖聚合结果，得两层嵌套 - 别漏掉
ELSE分支，否则NULL用户会被丢弃，导致总数对不上
为什么 COUNT + CASE 比 WHERE + GROUP BY 更灵活
因为你要的不是“每个用户登录几次”，而是“每个用户属于哪一级”，而等级边界往往交叉（比如同时看登录次数和最近一次行为时间）。这时候单靠 WHERE 过滤再 GROUP BY 无法表达多条件组合判断。
例如：「高活」定义为「近7天登录 ≥3 次 且 近30天有付费行为」，这种 AND 条件没法拆进多个 WHERE 分支里。
实操建议：
- 用
SUM(CASE WHEN ... THEN 1 ELSE 0 END)分别计算各维度达标次数，再在外部CASE里组合判断 - 避免在
CASE内部写子查询（如(SELECT COUNT(...) FROM ...)），会导致性能断崖——每行都触发一次子查询 - PostgreSQL 支持
COUNT(*) FILTER (WHERE ...)，比SUM(CASE...)更简洁，但 MySQL 不支持，跨库时优先选后者
容易被忽略的 NULL 和边界值陷阱
最常踩的坑：把「0次登录」和「NULL（压根没数据）」当成一回事。数据库里没记录 ≠ 登录0次，尤其当行为表是事件驱动时，沉默用户根本不出现在表里。
这意味着：如果你只查 user_behavior 表并 GROUP BY user_id，那些完全没行为的用户就彻底消失了。
实操建议：
- 需要包含全量用户时，必须从
users主表左连user_behavior，再用COUNT(behavior.user_id)或COUNT(*) FILTER (WHERE ...)计数（注意不是COUNT(*)，否则左连后 NULL 行也会被计为 1） - 等级边界用闭区间还是左闭右开？比如「1–5次」是否包含5？建议统一用
>=和<组合，避免BETWEEN在边界变更时出错 - 时间范围别硬写
'2024-01-01'，用CURRENT_DATE - INTERVAL '30 days'（PostgreSQL）或DATE_SUB(NOW(), INTERVAL 30 DAY)（MySQL），否则上线后逻辑就冻住了
MySQL 和 PostgreSQL 在 CASE 聚合里的关键差异
核心区别不在 CASE 本身，而在聚合函数对空值的处理和过滤语法。
比如统计「近7天有登录的用户数」：
- PostgreSQL 可写：
COUNT(*) FILTER (WHERE event_type = 'login' AND event_time >= CURRENT_DATE - INTERVAL '7 days') - MySQL 必须写：
SUM(CASE WHEN event_type = 'login' AND event_time >= DATE_SUB(NOW(), INTERVAL 7 DAY) THEN 1 ELSE 0 END) - 两者都支持标准
CASE，但 MySQL 不支持FILTER，也不支持在GROUP BY中直接引用SELECT别名（得重复写整个表达式） - 如果用到窗口函数配合等级（比如按活跃度分位数切桶），PostgreSQL 的
NTILE()直接可用，MySQL 8.0+ 才支持，且需确保排序字段无重复值，否则分桶不均
复杂点在于：活跃度定义本身常随业务滚动调整，今天看登录频次，明天加设备数、页面深度。一旦规则变，所有依赖它的报表 SQL 都得同步改——但没人记得住哪条 SQL 里埋了「登录≥3次算高活」这个 magic number。
