优先用SUM(CASE WHEN...)而非PIVOT，因其跨数据库通用、逻辑清晰、支持动态分类和空值精细控制；PIVOT仅SQL Server/Oracle原生支持，MySQL不支持，PostgreSQL语法受限，且必须硬编码列名、无法适配动态维度。
为什么直接用 SUM(CASE WHEN...) 比 PIVOT 更可控
因为 PIVOT 在 MySQL 中根本不存在，PostgreSQL 要 11+ 才支持（且语法僵硬），SQL Server 的 PIVOT 又要求硬编码列名——而真实业务里，统计维度常来自配置表或用户筛选。用 SUM(CASE WHEN...) 能把逻辑写死在 SQL 里，不依赖数据库版本，还能嵌套 COALESCE、NULLIF 做空值处理，调试也直观。
CASE WHEN 写法中容易漏掉的 NULL 处理
没加 ELSE 0 是最常见翻车点：只要某行不匹配任何 WHEN 条件，CASE 默认返回 NULL，而 SUM(NULL) 不报错但会跳过该行，导致总数变少。尤其当分类字段本身含 NULL 值时，必须显式覆盖。
-
SUM(CASE WHEN status = 'paid' THEN amount ELSE 0 END)—— 安全 -
SUM(CASE WHEN status = 'paid' THEN amount END)—— 危险：status 为NULL或'pending'的行全被忽略 - 若需保留原始
NULL语义（比如“未确认金额”不能算 0），改用SUM(CASE WHEN status = 'paid' THEN amount END) AS paid_amount，但得接受结果可能为NULL
多条件组合时 AND 要包在单个 WHEN 里，别拆成嵌套 CASE
想统计「2023 年高价值用户（order_count > 5）的退款金额」，错误写法是：SUM(CASE WHEN YEAR(create_time) = 2023 THEN CASE WHEN order_count > 5 THEN refund ELSE 0 END ELSE 0 END)。这不仅嵌套深、难读，还让优化器难以利用索引。正确方式是合并条件：
SUM(CASE WHEN YEAR(create_time) = 2023 AND order_count > 5 THEN refund ELSE 0 END) AS high_value_refund_2023
注意：MySQL 的 YEAR() 无法走 create_time 索引，生产环境应改用 create_time >= '2023-01-01' AND create_time 。
聚合后列名动态生成只能靠应用层拼接
SQL 标准不支持运行时生成列名。比如按产品线动态出「华东/华南/华北」三列，数据库查出来的永远是固定字段名 east_china、south_china、north_china。真要前端显示「华东销售额」这种带中文的标题，必须由应用代码（Python/Java/Node.js）把字段映射关系存配置里，SQL 只负责输出规范化的英文别名。
硬编码列名不是缺陷，是 SQL 的设计边界——它管数据怎么算，不管怎么叫。
