UNPIVOT 是 SQL 中将固定列转为行的操作，适用于已知列名、结构固定且类型一致的场景；不支持动态列名、混合类型或转行时计算，且默认过滤 NULL 值。
UNPIVOT 是什么，什么时候该用它
UNPIVOT 不是万能列转行方案，它只适合已知列名、结构固定、且目标列数据类型一致的场景。SQL Server 和 Oracle 支持原生 UNPIVOT，但 MySQL、PostgreSQL 完全不支持——强行查文档会踩坑。
- 适用：源表有
sales_q1、sales_q2、sales_q3等明确命名的数值列，想转成quarter和amount两列 - 不适用：列名动态（比如按日期生成的列）、列类型混杂（有的是
INT，有的是VARCHAR）、或需要在转行时做计算（如除以系数） - 注意：
UNPIVOT默认会过滤掉NULL值，如果原始列含空值且需保留，得先用COALESCE填充
UNION ALL 手动列转行更通用，但写法有讲究
当数据库不支持 UNPIVOT，或需要兼容多种方言时，UNION ALL 是最稳妥的选择。但它不是简单堆叠 SELECT，性能和可读性取决于怎么组织。
- 每段
SELECT必须字段数、顺序、类型完全一致，否则报错All queries combined using a UNION, INTERSECT or EXCEPT operator must have an equal number of expressions in their target lists - 显式转换类型：比如
CAST(sales_q1 AS DECIMAL(10,2))，避免隐式转换失败或精度丢失 - 别名统一放在第一段
SELECT，后续段不能重复写AS别名，否则部分数据库（如 SQL Server）会报语法错误 - 示例片段：
SELECT 'Q1' AS quarter, CAST(sales_q1 AS DECIMAL(10,2)) AS amount FROM sales_data UNION ALL SELECT 'Q2', CAST(sales_q2 AS DECIMAL(10,2)) FROM sales_data UNION ALL SELECT 'Q3', CAST(sales_q3 AS DECIMAL(10,2)) FROM sales_data
UNPIVOT 和 UNION ALL 的性能差异在哪
原生 UNPIVOT 在 SQL Server 上通常比等价的 UNION ALL 快 2–5 倍，因为它走的是优化器内置路径；但这个优势只在单表、小中量级数据（
-
UNPIVOT无法被大多数执行计划工具展开查看中间步骤，调试困难；UNION ALL每段都可单独执行验证 - MySQL/PostgreSQL 用户若用视图模拟
UNPIVOT（比如封装成函数），实际仍是UNION ALL展开，没有额外优化 - 大数据量下，两种方式都会触发全表扫描——真正影响性能的是是否对源列建了索引，而不是转行语法本身
容易被忽略的 NULL 处理和排序问题
列转行后默认不保证顺序，且原始 NULL 值可能意外消失或变成 0，这是线上出错最常见的原因。
-
UNPIVOT自动跳过NULL，如果业务要求保留空记录，必须提前用ISNULL(sales_q1, 0)或COALESCE(sales_q1, -1)占位，并在结果里再识别还原 -
UNION ALL不自动过滤NULL，但如果你写了WHERE sales_q1 IS NOT NULL就会漏数据——检查每段 WHERE 条件是否一致 - 转行后行序是数据库决定的，要按季度顺序排，必须加
ORDER BY quarter；如果用数字编码（如 1,2,3），记得用ORDER BY CAST(quarter AS INT)避免字典序错乱
