SQL列转行实战：UNPIVOT与UNION ALL的深度解析
在数据处理中，将多列数据“铺开”成多行记录，是一个高频且棘手的需求。面对这个任务，数据库开发者通常站在一个十字路口：一边是语法优雅但兼容性受限的UNPIVOT，另一边是朴实无华却处处需要小心的UNION ALL。
先说核心结论：追求简洁和语义清晰，UNPIVOT无疑是首选，但它只“服役”于SQL Server和Oracle等少数数据库。若想实现跨数据库兼容，UNION ALL是唯一可靠的路径，不过这条路需要格外注意数据类型对齐和NULL值处理这些“暗坑”。
UNPIVOT 语法怎么写？为什么常报错？
很多人误以为UNPIVOT能自动识别所有列，其实不然。它要求你明确地告诉数据库：要把哪几列“竖”起来，以及这些值应该放到哪两个新列里。这个过程必须手动指定源列和目标列名。
实际应用中，报错往往源于几个细节：
- 列选择错误：最常见的语法错误，是把作为标识的列（比如
id）也塞进了FOR ... IN子句里。这会导致数据库“困惑”，直接抛出Incorrect syntax near 'FOR'的错误。 - 数据类型冲突：所有要被转换的列，数据类型必须一致。如果一列是
INT，另一列是VARCHAR，数据库的隐式转换很可能失败。稳妥的做法是提前用CAST统一类型。 - NULL值“消失”：这是
UNPIVOT一个关键特性——原表中值为NULL的单元格，在结果集中会被直接过滤掉，不会生成对应的行。这一点与UNION ALL的行为截然不同。
来看一个SQL Server的示例，它清晰地展示了如何规避上述问题：
SELECT id, attribute, value
FROM (
SELECT id, CAST(age AS VARCHAR(10)) AS age,
CAST(score AS VARCHAR(10)) AS score
FROM students
) AS src
UNPIVOT (value FOR attribute IN (age, score)) AS up;
UNION ALL 替代方案：怎么避免类型不匹配和重复扫描？
当环境切换到MySQL、PostgreSQL，或者需要编写跨数据库的通用脚本时，UNION ALL就成了不二之选。它的本质是“手动拼接”：为每一列单独写一个SELECT语句，再把所有结果集合并起来。
这种方法虽然直接，但陷阱也不少：
- 结构必须严丝合缝：每个
SELECT子句的列数、顺序、数据类型必须完全一致。一个常见的技巧是将所有值都转换为TEXT或VARCHAR，从源头上杜绝类型不匹配。 - 警惕性能杀手：务必使用
UNION ALL，而不是UNION。除非你确实需要去重，否则UNION带来的额外排序和去重操作，会对性能造成显著拖累。 - 小心重复扫描：如果原表数据量巨大，每个
SELECT都会触发一次全表扫描。此时，可以考虑为查询添加覆盖索引，或者先将数据导入临时表再进行操作，以减轻数据库负担。
下面是一个通用的SQL示例，演示了如何安全地使用UNION ALL：
SELECT id, 'age' AS attribute, CAST(age AS VARCHAR(20)) AS value FROM students UNION ALL SELECT id, 'score' AS attribute, CAST(score AS VARCHAR(20)) AS value FROM students;
NULL 值处理差异：UNPIVOT 丢行，UNION ALL 保留
这才是真正考验功力的地方。对于同一行中值为NULL的列，两种方法的行为天差地别，而下游的业务逻辑往往对此有隐含的依赖。
UNPIVOT的选择性忽略：它会直接跳过值为NULL的单元格，不会为它生成输出行。比如，某学生的age为NULL，那么结果中就不会出现(id, 'age', NULL)这条记录。UNION ALL的忠实记录：与之相反，UNION ALL会原封不动地保留NULL值，生成一行记录。如果你的后续统计或关联操作需要依赖这些NULL行作为占位，那么这一点至关重要。- 如何调和矛盾：如果坚持使用
UNPIVOT但又需要保留NULL行，必须在转换前做预处理。使用ISNULL()或COALESCE()函数，将NULL替换为一个有意义的默认值（比如空字符串），然后再进行列转行操作。
说到底，写出正确的SQL语句只是第一步。真正的难点在于预判：判断哪些列可能存在NULL、评估目标数据库是否支持UNPIVOT、确认下游应用是否依赖空值占位。这些细节，往往在系统上线后才会暴露出来，成为需要紧急修复的“暗雷”。
