最稳妥方式是用COUNT(CASE WHEN status='active' THEN 1 END)统计多状态用户数，因COUNT自动忽略NULL，避免ELSE 0导致虚高；需注意WHERE与CASE的过滤时机差异及status字段索引优化。
用 CASE WHEN + COUNT 统计多状态用户数
直接在 COUNT 里套 CASE WHEN 是最常用、兼容性最好的方式。它不依赖窗口函数或复杂子查询，MySQL 5.7、PostgreSQL、SQL Server、Oracle 都能跑。
常见错误是写成 COUNT(CASE WHEN status='active' THEN 1 ELSE 0 END) —— 这会把 0 当作非空值计入，导致总数虚高。正确做法是让 ELSE 返回 NULL，因为 COUNT 只统计非 NULL 值。
-
COUNT(CASE WHEN status = 'active' THEN 1 END)✅（隐式ELSE NULL） -
COUNT(CASE WHEN status = 'active' THEN 1 ELSE NULL END)✅（显式更清晰） -
COUNT(CASE WHEN status = 'active' THEN 1 ELSE 0 END)❌（0被计数）
示例：
SELECT COUNT(CASE WHEN status = 'active' THEN 1 END) AS active_count, COUNT(CASE WHEN status = 'inactive' THEN 1 END) AS inactive_count, COUNT(CASE WHEN status = 'pending' THEN 1 END) AS pending_count FROM users;
用 SUM + CASE 替代 COUNT 的适用场景
当需要同时支持布尔条件聚合（比如 MySQL 中 TRUE=1）、或后续要加权计算时，SUM(CASE ...) 更灵活。它本质是把每个匹配行转成 1 或 0 再求和，语义明确，且不会因误写 ELSE 出错。
注意：在严格模式的 PostgreSQL 或 SQL Server 中，SUM 对空集返回 NULL，而 COUNT 返回 0。如果业务要求空状态下必须显示 0，得补 COALESCE(SUM(...), 0)。
- 适合需要扩展逻辑的场景，比如 “活跃且注册超30天”：
SUM(CASE WHEN status='active' AND DATEDIFF(NOW(), created_at) > 30 THEN 1 ELSE 0 END) - 避免漏写
ELSE 0—— 不写默认为NULL，会被SUM忽略，结果偏小
GROUP BY 和 WHERE 的边界必须分清
如果只想要「全局统计」不同状态人数，就别加 GROUP BY status；一旦加了，结果会按每种状态拆成多行，不再是单行宽表结构。
另一个高频陷阱是混淆过滤时机：WHERE status IN ('active','inactive') 会先筛出行，再聚合，丢失 pending 状态的计数；而 CASE WHEN 在聚合内完成判断，所有行都参与计算。
- 要“总览所有状态分布” → 用
CASE WHEN+ 单行SELECT，不GROUP BY - 要“只看某几个状态的合计” → 用
WHERE先过滤，再GROUP BY或单字段COUNT(*) - 混合需求？比如“活跃用户数”和“其他用户数”，可写：
COUNT(CASE WHEN status='active' THEN 1 END)和COUNT(CASE WHEN status != 'active' THEN 1 END)
性能与索引注意事项
这类聚合本身不慢，但数据量大时，status 字段有没有索引会影响全表扫描开销。尤其当加上时间范围（如 created_at > '2024-01-01'）后，复合索引 (status, created_at) 或 (created_at, status) 就很关键 —— 具体顺序取决于查询中哪个条件选择性更高。
另外，如果 status 是字符串且存在大量空值或重复值（比如 95% 是 'inactive'），某些数据库优化器可能放弃索引走全表扫描。这时可以考虑生成列+索引（MySQL 5.7+）或物化视图（PostgreSQL）缓存统计结果。
别忘了检查执行计划：EXPLAIN SELECT ... 看是否命中索引、是否用到临时表或文件排序。
