如何利用SQL子查询实现列转行操作：嵌套CASE WHEN逻辑分析
子查询里不能直接用CASE WHEN做列转行？先搞清执行顺序
很多朋友一看到“列转行”，下意识就想用CASE WHEN去解决。但这里有个根本性的误区：CASE WHEN本身并不改变行数，它只是在每一行内部做条件判断和值映射。真正的“列转行”，本质是把一张表里横向排列的多个列值，变成纵向的多行记录——这需要的是能扩展行数的操作，而不是单点映射。
举个例子，如果你在子查询里只包一层CASE WHEN，比如SELECT id, (SELECT CASE WHEN type=1 THEN name END) AS val FROM t，结果会怎样？首先，语法上就可能报错，因为子查询缺少FROM且未关联外层。退一步讲，即便语法通了，它返回的也只是一个标量值，根本变不出多行来。
所以，真正能实现列转行的路径，其实就两条：要么用兼容性极高的UNION ALL把各列拆开再合并；要么用LATERAL（PostgreSQL/SQL Server）或APPLY（SQL Server）配合VALUES来构造行集。后者更简洁，但前者才是“万金油”。
用UNION ALL + 子查询实现安全列转行（MySQL/Oracle/SQL Server通吃）
假设你手头有张表t，里面有id、col_a、col_b、col_c四列。现在想把它转成id、col_name、col_value这样的三列多行结构。核心思路很直接：把每个列都单独写成一个子查询，然后用UNION ALL把它们拼起来，并且每条子查询都要显式带上id和列名的标识。
具体操作看下面这个例子：
SELECT id, 'col_a' AS col_name, col_a AS col_value FROM t UNION ALL SELECT id, 'col_b', col_b FROM t UNION ALL SELECT id, 'col_c', col_c FROM t ORDER BY id, col_name;
这里有三个细节需要特别注意：
- 字段一致性：所有
UNION ALL分支的字段数量、数据类型必须严格对齐。如果col_a、col_b、col_c类型不同，最好先做显式转换，否则在MySQL里可能会遇到Illegal mix of collations这类错误。 - 用ALL，别用UNION：列转行场景下，各分支结果天然就是不同的，不需要去重。用
UNION ALL能避免不必要的去重开销，性能更好。 - 过滤时机：别急着在子查询里加
WHERE条件过滤原始数据。如果各分支过滤后的行数不一致，UNION ALL就会出错。正确的做法是在最外层统一加WHERE。
嵌套CASE WHEN真正该用在哪？配合行转列反向校验
那么，CASE WHEN是不是就没用了？当然不是。很多人把它用错了地方——它不适合“创造”新行，但非常适合对已经转成行的数据进行条件分类和标记。
举个例子，针对上面UNION ALL生成的结果，如果你想区分哪些值是“主名称”，哪些是“备用名称”，就可以在外层嵌套一个CASE WHEN：
SELECT
id,
col_name,
col_value,
CASE
WHEN col_name IN ('col_a', 'col_b') THEN 'primary'
WHEN col_name = 'col_c' THEN 'backup'
ELSE 'unknown'
END AS category
FROM (
SELECT id, 'col_a' AS col_name, col_a AS col_value FROM t
UNION ALL
SELECT id, 'col_b', col_b FROM t
UNION ALL
SELECT id, 'col_c', col_c FROM t
) t2;
这里的关键区别在于：
CASE WHEN作用的对象，已经是扩展后的多行数据，它不再试图改变行数，只是给每行打上一个分类标签。- 子查询只负责提供干净的“数据源”，所有业务判断逻辑都放在外层的
SELECT里。如果把CASE WHEN塞进每个UNION ALL分支内部，不仅代码冗余，还容易因为各分支逻辑不一致导致分类混乱。
性能和可维护性陷阱：别让列转行变成定时冲击波
方法虽然可行，但隐患也不少。最直接的问题就是性能：列数越多，UNION ALL的分支就越多，执行计划会变得复杂。10列就意味着要扫描原表10次——这不是优化能完全解决的，是方案本身的硬伤。
在实际项目中，更稳妥的做法通常是：
- 优先在应用层处理：直接从数据库读出原始行，然后在Python、Ja va等应用代码里用循环或流式方式构造新行。这样能避免数据库反复扫描同一张表。
- SQL内处理的边界：如果必须在SQL里完成，且列数固定且不多（比如≤5列），用
UNION ALL还算稳定。一旦超过5列，强烈建议建个视图把UNION ALL逻辑封装起来，别让这套冗长的代码散落在业务SQL的各个角落。 - 警惕“伪方案”：千万别为了图省事，用
JSON_OBJECT或CONCAT把多列拼成一个字符串假装“转行”了。这么干，后续的索引、条件过滤、表关联全都无法高效进行，等于给自己埋了个大坑。
最后再提一个容易踩的坑：列转行之后，原来的id很可能就不再是唯一键了。这时候如果要做GROUP BY或DISTINCT，必须明确指定聚合的粒度，否则结果会错得悄无声息，排查起来非常头疼。
