UNPIVOT是SQL Server中的关系运算符，需在FROM子句中使用，将多列转为行；要求IN列表列类型一致，自动过滤NULL，不支持跨数据库；替代方案包括UNION ALL或动态SQL。
UNPIVOT 语法结构和基本写法
UNPIVOT 不是函数，而是 SQL Server（及部分兼容引擎）中的关系运算符，用于将多列“堆叠”成行。它必须配合 SELECT 使用，不能单独调用。核心结构是：先定义要“展开”的列集合（FOR 后的列名），再指定新生成的列名（IN 列表中原始列名），最后声明值列和类别列。
常见错误是把 UNPIVOT 当成函数写在 SELECT 列表里，比如 UNPIVOT(value FOR col IN (a,b,c)) —— 这会直接报错 Incorrect syntax near 'UNPIVOT'。正确写法必须作为子句出现在 FROM 子句中：
SELECT id, category, value FROM source_table UNPIVOT (value FOR category IN (col1, col2, col3)) AS u;
注意：UNPIVOT 默认丢弃 NULL 值，如果原始列含空值且需保留，得先用 ISNULL 或 COALESCE 替换。
UNPIVOT 在 SQL Server 中的实际限制
UNPIVOT 只支持 SQL Server 和 Azure SQL Database，MySQL、PostgreSQL、SQLite 均不支持。PostgreSQL 用户得用 UNION ALL 模拟，MySQL 8.0+ 可借助 JSON_TABLE 或横向连接（LATERAL），但语义和性能差异大。
另一个关键限制：所有被 IN 列出的列必须是相同数据类型。例如，col1 INT、col2 VARCHAR(10) 一起进 UNPIVOT 会触发 Cannot convert data type 错误。解决方法只有显式转换：
- 统一转为
VARCHAR：CAST(col1 AS VARCHAR(20)), CAST(col2 AS VARCHAR(20)) - 或提前在子查询中做类型对齐
别指望 UNPIVOT 自动隐式转换——它比 SELECT 更严格。
替代方案：当 UNPIVOT 不可用或太僵硬时
如果目标数据库不支持 UNPIVOT，或字段数量动态变化（比如列名来自配置表），硬写 IN (c1,c2,c3,...) 就不可维护。此时更通用的做法是用 UNION ALL 手动展开：
SELECT id, 'col1' AS category, col1 AS value FROM t UNION ALL SELECT id, 'col2', col2 FROM t UNION ALL SELECT id, 'col3', col3 FROM t;
虽然啰嗦，但它跨数据库、可参数化、能保留 NULL，且每条分支可独立加 WHERE 条件。缺点是字段越多，SQL 越长，也难做元数据驱动。
另外，SQL Server 2016+ 用户可考虑 STRING_AGG + 动态 SQL 拼接 UNPIVOT，但要注意注入风险和执行计划缓存问题——不是所有场景都值得这么折腾。
UNPIVOT 性能与 NULL 处理的隐性开销
UNPIVOT 内部会做一次完整扫描 + 行重组，对大表来说，它比等价的 UNION ALL 略慢，尤其当源表有聚集索引但未按 id 排序时。执行计划里常出现 Compute Scalar 和 Concatenation 算子，说明有隐式转换或构造开销。
最易被忽略的是 NULL 过滤行为：只要任意一个被 unpivot 的列值为 NULL，整行就消失。比如原始行是 (1, NULL, 5)，结果里只会出现 (1, 'col2', 5)，而 col1 的 NULL 不会生成对应记录。若业务逻辑要求保留空位，必须预先填充占位符（如 '[NULL]'），并在后续清洗。
实际用的时候，先确认数据库版本和类型，再看字段是否同质、是否允许丢 NULL——这三个点没对齐，UNPIVOT 就容易变成陷阱。
