派生表子查询适合做透视前的数据准备，因其能封装清洗、映射、标准化逻辑，避免pivot或case when因null、类型不一致、字段未对齐等报错；必须显式列出字段并设别名，时间转标准日期，指标字段需coalesce兜底null。
派生表子查询为什么适合做透视前的数据准备
因为真实业务数据往往带冗余、空值、格式不一，直接在主查询里写 PIVOT 或嵌套 CASE WHEN 容易报错或漏行。派生表能把清洗、映射、标准化逻辑封装在子查询里，主查询只管聚合和展开——结构清晰，调试也方便。
常见错误现象：PIVOT 报 “无效的列名” 或 “聚合函数缺少”，往往是源数据里有 NULL、类型不一致（比如 year 字段存了字符串 '2024' 和整数 2025），或者分组字段没对齐。这些问题在派生表里提前处理掉，主查询就稳了。
- 派生表必须有别名（如
AS src），否则 MySQL/SQL Server 都会报错 - 所有用于后续
CASE WHEN或PIVOT的字段，必须在派生表 SELECT 中显式写出，不能依赖* - 时间字段建议统一转成标准日期类型（如用
CAST(order_date AS DATE)），避免DATEPART或YEAR()出现隐式转换失败
MySQL 不支持 PIVOT 时，用派生表 + CASE WHEN 实现等效透视
MySQL 没有原生 PIVOT，但靠派生表把“分类逻辑”和“聚合逻辑”拆开，反而更可控。关键不是堆 CASE，而是让派生表输出规整的“维度列 + 指标列”结构。
例如：要把订单按「状态」和「季度」交叉统计，原始表只有 status、order_date、amount 三列：
SELECT
status,
SUM(q1_amt) AS q1,
SUM(q2_amt) AS q2,
SUM(q3_amt) AS q3,
SUM(q4_amt) AS q4
FROM (
SELECT
status,
CASE WHEN QUARTER(order_date) = 1 THEN amount ELSE 0 END AS q1_amt,
CASE WHEN QUARTER(order_date) = 2 THEN amount ELSE 0 END AS q2_amt,
CASE WHEN QUARTER(order_date) = 3 THEN amount ELSE 0 END AS q3_amt,
CASE WHEN QUARTER(order_date) = 4 THEN amount ELSE 0 END AS q4_amt
FROM orders
WHERE order_date >= '2025-01-01'
) AS src
GROUP BY status;
- 派生表里每个
CASE WHEN都带ELSE 0，确保 SUM 不跳过任何行 - WHERE 放在派生表内，而不是外层，减少主查询扫描量
- 别在派生表里用
GROUP BY—— 那会提前压缩数据，导致外层无法按多维展开
SQL Server 中用派生表配合 PIVOT 避免动态列硬编码
SQL Server 的 PIVOT 要求列名写死，但业务常需按最新 N 个年份生成列。这时派生表可先算出目标年份列表，再拼进动态 SQL —— 但注意：派生表本身不能执行动态逻辑，它只是中间结果载体。
真正安全的做法是：派生表负责“标准化输入”，比如把原始年份映射为固定标签：
SELECT category, year_label, qty
FROM (
SELECT
category,
CASE
WHEN YEAR(order_date) = YEAR(GETDATE()) THEN 'Current'
WHEN YEAR(order_date) = YEAR(GETDATE()) - 1 THEN 'Last'
ELSE 'Older'
END AS year_label,
qty
FROM sales
) AS labeled;
这个结果集就能直接喂给 PIVOT：
SELECT category, [Current], [Last], [Older] FROM (/* 上面的派生表查询 */) AS src PIVOT (SUM(qty) FOR year_label IN ([Current], [Last], [Older])) AS p;
- 派生表把年份归类为稳定字符串（
'Current'等），规避了动态列名问题 - 所有
IN列表里的值，必须和派生表中year_label的实际取值完全一致（大小写、空格都不能差） - 如果某类无数据，对应列返回 NULL —— 这是正常行为，不是派生表错了
容易被忽略的 NULL 传导链
最隐蔽的坑不在 PIVOT 或 CASE WHEN 本身，而在派生表上游：如果原始字段含 NULL，又没在派生表里显式处理，它会一路透传到外层聚合，导致 SUM 返回 NULL 而不是 0。
例如：订单表中 amount 允许为空，但你在派生表里直接 SELECT amount，后续 SUM(amount) 就可能为 NULL —— 即使加了 ELSE 0 也没用，因为 NULL 已经进来了。
- 派生表中对可能为 NULL 的指标字段，必须用
COALESCE(amount, 0)或ISNULL(amount, 0)（SQL Server）兜底 - 分类字段（如
status）含 NULL 时，CASE WHEN status = 'paid'永远不匹配，得加WHEN status IS NULL THEN 'unknown'分支 - 别依赖应用层补 0 —— 数据库层没处理干净，下游无论怎么 SUM 都救不回来
