推荐用 sum(case when ... then 1 else 0 end) 实现多条件独立计数，避免多次查询或 count(case...) 的 null 陷阱，一次扫描完成所有统计，兼容主流数据库，注意 null 处理与索引优化。
用 CASE WHEN + SUM 实现多条件独立计数
直接在 SELECT 中对每个条件写一个 SUM(CASE WHEN ... THEN 1 ELSE 0 END)，比多次子查询或 UNION 快得多，也比 COUNT(CASE ...) 更稳妥（因为 COUNT 会忽略 NULL，但漏写 ELSE 0 容易误统计）。
常见错误是写成 COUNT(CASE WHEN status = 'paid' THEN 1 END) —— 这其实只统计非 NULL 行，等价于 COUNT(*) 在该分支下的行数，但一旦没写 ELSE 0，就丢失了“不满足时计 0”的语义，容易和预期不符。
-
SUM更直白：满足加 1，不满足加 0，总和就是命中数 - 所有条件在同一扫描中完成，避免重复全表/索引扫描
- MySQL、PostgreSQL、SQL Server、Oracle 都支持，语法一致
SELECT SUM(CASE WHEN status = 'paid' THEN 1 ELSE 0 END) AS paid_count, SUM(CASE WHEN status = 'refunded' THEN 1 ELSE 0 END) AS refunded_count, SUM(CASE WHEN created_at >= '2024-01-01' AND amount > 100 THEN 1 ELSE 0 END) AS big_new_orders FROM orders;
WHERE 和 HAVING 不适合多条件独立计数
有人试图用多个 WHERE 分别查再 JOIN，或者想靠 HAVING 筛聚合结果——这行不通。WHERE 是行级过滤，会把不满足条件的行整个剔除，无法在同一次扫描里保留所有原始行来分别判断；HAVING 是对分组后结果的过滤，不能生成多个并列的计数值。
典型误用：
-- ❌ 错误：WHERE 只能选一种条件，无法并行统计 SELECT COUNT(*) FROM orders WHERE status = 'paid'; SELECT COUNT(*) FROM orders WHERE status = 'refunded';
这类写法要发两次查询，应用层还得合并，网络和解析开销翻倍，且无法保证事务一致性（中间数据可能变更）。
注意 NULL 值和布尔表达式的陷阱
如果字段本身可能为 NULL（比如 status 允许为空），直接写 status = 'paid' 判断会返回 NULL 而非 FALSE，导致 CASE 走不到 ELSE 分支——所以更安全的写法是显式排除：
- 用
status IS NOT NULL AND status = 'paid' - 或用
COALESCE(status, '') = 'paid'（取决于语义是否允许空字符串等价） - 聚合字段含 NULL 时，
SUM本身会跳过 NULL，但我们的CASE已经用ELSE 0覆盖，所以没问题
另外，某些数据库（如 PostgreSQL）支持布尔值直接参与算术运算：SUM((status = 'paid')::int)，但这是方言特性，跨库可移植性差，不建议依赖。
复杂条件建议抽成 CTE 或子查询提升可读性
当单个 CASE 里逻辑嵌套三层以上（比如多重 AND/OR + 函数调用），SQL 很快变得难维护。此时可先用 CTE 抽出逻辑标记列：
WITH labeled AS (
SELECT *,
(status = 'paid' AND amount > 0) AS is_valid_paid,
(status = 'refunded' AND refund_time IS NOT NULL) AS is_full_refund
FROM orders
)
SELECT
SUM(is_valid_paid::int) AS valid_paid_count,
SUM(is_full_refund::int) AS full_refund_count
FROM labeled;
这样每行标记清晰，后续聚合一目了然；而且 PostgreSQL 和 SQL Server 支持布尔转整型，MySQL 需改用 IF(is_valid_paid, 1, 0)。
真正容易被忽略的是：多个独立计数看似简单，但一旦涉及时区转换、隐式类型转换（比如字符串和数字比较）、或函数索引不可用（如 DATE(created_at)），性能可能断崖下跌——别只盯着语法，先看执行计划里的扫描方式和是否用上索引。
