COUNT(CASE WHEN...)更灵活，因单条SELECT可同时计算多条件计数，无需多次JOIN或子查询；需确保CASE各分支返回1或NULL，避免隐式转换错误。

为什么 COUNT(CASE WHEN ...) 比 WHERE + GROUP BY 更灵活？

因为单条 SELECT 语句里能同时算多个条件维度的计数，不用反复 JOIN 或子查询。比如统计「订单总数、已支付数、已发货数、超时未支付数」，全在一个聚合里搞定。

• COUNT() 遇到 NULL 就跳过，所以 CASE WHEN 必须显式写 ELSE NULL（或不写 ELSE），否则默认补 ELSE NULL 是安全的
• 别用 SUM(CASE WHEN ... THEN 1 ELSE 0 END) 代替——语义不清，且在某些数据库（如旧版 MySQL）里可能因隐式类型转换出错
• 如果字段本身含 NULL，注意 WHEN status = 'paid' 不会匹配 status IS NULL，这是预期行为，不是 bug

CASE WHEN 在 COUNT 内部怎么写才不出错？

核心是：让每个分支返回确定值（通常是 1 或 NULL），且只在满足条件时返回非 NULL。

SELECT
  COUNT(*) AS total,
  COUNT(CASE WHEN status = 'paid' THEN 1 END) AS paid_count,
  COUNT(CASE WHEN status IN ('shipped', 'delivered') THEN 1 END) AS shipped_count,
  COUNT(CASE WHEN created_at 

• CASE WHEN ... THEN 1 END 省略 ELSE 等价于 ELSE NULL，安全
• 不要写 CASE WHEN ... THEN 'yes' END——字符串不能被 COUNT 当有效值计数（多数数据库会静默转成 NULL，但行为不统一）
• PostgreSQL 对 THEN 表达式类型敏感；若混用数字和字符串，会报错，必须保持分支返回类型一致

遇到 COUNT 始终为 0 或结果偏少怎么办？

常见原因不是语法错，而是逻辑没覆盖全或 NULL 处理不当：

• 检查条件是否遗漏了 NULL 分支：比如想统计「非成功状态」，写了 WHEN status != 'success'，但 status IS NULL 不满足该条件，也不会被计入——需要加 WHEN status IS NULL OR status != 'success' 或单独处理
• 时间比较出错：如用 created_at 但字段是 TIMESTAMP WITH TIME ZONE，而字符串字面量按本地时区解析，导致漏数据
• 条件顺序影响结果：多个 CASE 分支有重叠时（如 status = 'paid' 和 status IN ('paid','refunded')），只要第一个匹配就退出，后续不执行——这不是问题，是 CASE 的定义行为

不同数据库对 CASE WHEN 聚合的支持差异

绝大多数标准 SQL 数据库都支持，但细节有坑：

• MySQL 5.7+ 支持完整语法，但早期版本对 CASE 中子查询限制较严
• SQLite 允许 CASE 返回任意类型，但 COUNT 只认非 NULL，所以仍建议统一用 1 或 NULL
• SQL Server 2016+ 支持 STRING_AGG 配合 CASE 做条件拼接，但 COUNT 用法完全一致
• 注意：COUNT(DISTINCT CASE WHEN ...) 在部分老版本 Oracle 中不支持，需改用 SUM + DECODE 替代

真正容易被忽略的是：当条件涉及关联表字段时，CASE 写在主表 SELECT 里，但关联为空（LEFT JOIN 产生 NULL）会导致整个分支返回 NULL——这时得提前在 ON 或子查询里过滤，而不是靠 CASE 补救。