直接用sum(case when...)比嵌套子查询更可靠，因其天然兼容聚合层级，避免“混合聚合与非聚合列”错误；无需预分组，通过横向切片实现多维度汇总，且else 0确保null不导致断层或漏统。
为什么直接用 SUM(CASE WHEN ...) 比嵌套子查询更可靠？
因为 SUM 是聚合函数，而 CASE WHEN 在 SELECT 中是非聚合表达式——二者天然兼容，只要写在同一个聚合层级下，就能避免“混合了聚合和非聚合列”的错误（比如 MySQL 5.7 默认 SQL mode 下报错 ERROR 1140: In aggregated query without GROUP BY）。关键在于：你不需要提前分组，CASE WHEN 只是生成临时数值，SUM 再对这些数值求和。
常见错误是把 CASE WHEN 写在 GROUP BY 里，或者误以为要先 GROUP BY category 才能统计各分类——其实完全不需要，SUM+CASE 的本质是“横向切片统计”，不是分组后聚合。
怎么写一个带条件的多维度汇总（比如按状态计数+金额合计）？
典型场景：一张订单表 orders，字段有 status（'paid', 'shipped', 'cancelled'）、amount。你想一行返回每种状态的订单数和对应总金额：
SELECT SUM(CASE WHEN status = 'paid' THEN 1 ELSE 0 END) AS paid_count, SUM(CASE WHEN status = 'paid' THEN amount ELSE 0 END) AS paid_amount, SUM(CASE WHEN status = 'shipped' THEN 1 ELSE 0 END) AS shipped_count, SUM(CASE WHEN status = 'shipped' THEN amount ELSE 0 END) AS shipped_amount, SUM(CASE WHEN status = 'cancelled' THEN 1 ELSE 0 END) AS cancelled_count, SUM(CASE WHEN status = 'cancelled' THEN amount ELSE 0 END) AS cancelled_amount FROM orders;
注意点：
-
ELSE 0必须写，否则遇到不匹配行会返回NULL，而SUM(NULL)不影响结果，但SUM(1, NULL)仍得 1；可读性和一致性上，显式写0更安全 - 不要用
COUNT(CASE WHEN ...)替代SUM(CASE WHEN ... THEN 1 ELSE 0)，因为COUNT会忽略NULL，但语义不如SUM直观，且在某些数据库（如 older PostgreSQL）中可能触发隐式类型转换警告 - 如果
amount允许为NULL，建议先用COALESCE(amount, 0)包裹，避免SUM计算时跳过整行
遇到 NULL 值或空字符串导致汇总不准怎么办？
当分类字段本身含 NULL 或空字符串（比如 status IS NULL 或 status = ''），CASE WHEN status = 'paid' 会直接跳过，这部分数据既不进任何分支，也不被统计——容易漏数。
解决方法是显式覆盖所有情况：
SELECT SUM(CASE WHEN status = 'paid' THEN 1 ELSE 0 END) AS paid_count, SUM(CASE WHEN status = 'shipped' THEN 1 ELSE 0 END) AS shipped_count, SUM(CASE WHEN status IS NULL OR status = '' THEN 1 ELSE 0 END) AS unknown_status_count FROM orders;
另外，WHERE 过滤和 CASE 分支要区分清楚：如果你加了 WHERE status IS NOT NULL，那后面 CASE 就不用再处理 NULL；但一旦用了 WHERE，就再也统计不到被过滤掉的数据——所以优先用 CASE 内部兜底，而不是依赖 WHERE。
性能差？别急着加索引，先看执行计划里有没有 TABLE SCAN
SUM(CASE WHEN ...) 本身不阻止索引使用，但数据库优化器是否走索引，取决于整个查询结构。比如下面这句：
SELECT SUM(CASE WHEN created_at > '2024-01-01' AND status = 'paid' THEN amount ELSE 0 END) FROM orders;
如果 created_at 和 status 没有联合索引，MySQL/PostgreSQL 很可能全表扫描。此时应该建复合索引：CREATE INDEX idx_created_status ON orders (created_at, status);
但注意：索引列顺序很重要。把高选择性字段（如 created_at）放前面，能让范围扫描更高效；如果反过来建 (status, created_at)，优化器大概率放弃索引，因为 status = 'paid' 匹配太多行，后续 created_at > ... 就没法利用索引排序优势。
真正容易被忽略的是：这类汇总常出现在报表页，而报表 SQL 往往没加 LIMIT 或缓存机制——一次查几百万行，SUM+CASE 再快也扛不住。该加物化视图（PostgreSQL）或汇总表（MySQL）的时候，别硬扛。
