SUM(CASE WHEN...)能替代PIVOT，因为MySQL、PostgreSQL、SQLite等多数数据库不原生支持PIVOT，而该写法是ANSI标准、跨库兼容的行转列方案，通过CASE构造条件列并用SUM聚合，需显式ELSE 0及完整GROUP BY。
为什么直接用 SUM(CASE WHEN ...) 能替代 PIVOT？
因为多数数据库（MySQL、PostgreSQL、SQLite）不原生支持 PIVOT，而 SUM + CASE WHEN 是 ANSI SQL 标准写法，兼容性好、逻辑直白。核心思路是：对每个目标列，用 CASE WHEN 把符合条件的行转为数值（通常是 1 或实际字段值），其余转为 0，再用 SUM 汇总——本质是“条件计数”或“条件求和”。
常见错误现象：CASE WHEN 忘记 ELSE 0，导致某列出现 NULL，SUM 结果变 NULL；或漏写 GROUP BY，结果只有一行。
- 必须为每个
CASE WHEN显式指定ELSE 0（不能省略） -
GROUP BY的字段必须覆盖所有非聚合列（如报表的行维度字段） - 若需统计数量，
CASE WHEN ... THEN 1 ELSE 0 END；若需汇总金额，CASE WHEN ... THEN amount ELSE 0 END
如何按月份+产品生成销售交叉表？
这是最典型场景：行是产品，列是月份，单元格是当月销售额。关键在于把时间字段（如 order_date）转换成离散的列名（如 "Jan"、"Feb"），同时保证分组正确。
SELECT product_name, SUM(CASE WHEN EXTRACT(MONTH FROM order_date) = 1 THEN sales_amount ELSE 0 END) AS Jan, SUM(CASE WHEN EXTRACT(MONTH FROM order_date) = 2 THEN sales_amount ELSE 0 END) AS Feb, SUM(CASE WHEN EXTRACT(MONTH FROM order_date) = 3 THEN sales_amount ELSE 0 END) AS Mar FROM orders GROUP BY product_name;
注意点：
- PostgreSQL 用
EXTRACT(MONTH FROM ...)，MySQL 用MONTH(order_date)，SQLite 用strftime('%m', order_date) - 列别名（
Jan）不能带空格或特殊字符，否则需用双引号（PostgreSQL）或反引号（MySQL）包裹 - 如果某产品某月无数据，该单元格自动为 0（得益于
ELSE 0），不是NULL
遇到 NULL 值或空字符串怎么安全处理？
当源字段本身含 NULL（如 sales_amount 可为空），直接参与 SUM 不影响结果（SUM 自动忽略 NULL），但 CASE WHEN 的条件判断可能出错。例如：CASE WHEN status = 'paid' THEN amount，若 status 是 NULL，整个条件为未知（UNKNOWN），走不到 THEN 分支，也走不到 ELSE（除非显式写 ELSE）。
- 永远在
CASE WHEN末尾加ELSE 0，不要依赖默认行为 - 对可能为
NULL的判断字段，用COALESCE(status, '') = 'paid'或status IS NOT DISTINCT FROM 'paid'（PostgreSQL） - 避免在
THEN中直接写amount，改用COALESCE(amount, 0)防止整列被拖成NULL
性能差、查询卡顿怎么办？
交叉表查询本质是多遍扫描同一张表（每个 CASE WHEN 算一列），当数据量大、列数多时，I/O 和 CPU 开销明显上升。这不是语法问题，而是模式限制。
- 确保
WHERE过滤尽早执行（比如先加WHERE order_date >= '2024-01-01'再分组） - 给分组字段（如
product_name）和条件字段（如order_date、status）建联合索引 - 列数超过 5–6 个时，考虑在应用层拼接（如 Python pandas 的
pivot_table），数据库只返回明细 - MySQL 8.0+ 可尝试
JSON_OBJECTAGG+ 应用层解析，避免硬编码列名
最易被忽略的是：没意识到这种写法本质上是“宽表展开”，一旦业务要求动态列（比如按用户自选年份），SQL 就必须重写——这时候就该让步给应用层了。
