不是必须。UNPIVOT仅适用于SQL Server 2005+中列名固定、类型一致的场景，且默认过滤NULL；通用替代方案是CROSS APPLY VALUES，语义清晰、可控性强，支持显式NULL处理和动态扩展。
SQL Server列转行必须用UNPIVOT吗
不是必须。UNPIVOT是SQL Server 2005+提供的专用语法，但仅适用于已知列名、结构固定的场景；一旦列名动态（比如每月新增一列）、或含NULL值需过滤，UNPIVOT反而容易出错或写不下去。更通用的做法是用VALUES表构造器 + CROSS APPLY，它语义清晰、可控性强，且不依赖列名硬编码。
用CROSS APPLY VALUES实现列转行的典型写法
假设有一张用户联系信息表user_contact，结构为：user_id, mobile, email, wechat，目标是转成三列：user_id, contact_type, contact_value。
正确写法如下：
SELECT u.user_id, v.contact_type, v.contact_value
FROM user_contact u
CROSS APPLY (VALUES
('mobile', u.mobile),
('email', u.email),
('wechat', u.wechat)
) AS v(contact_type, contact_value)
WHERE v.contact_value IS NOT NULL;
关键点：
-
VALUES里每组括号对应一行输出，字段顺序必须和v(...)别名定义一致 -
WHERE v.contact_value IS NOT NULL必须显式加——UNPIVOT默认会跳过NULL，但VALUES不会 - 如果某列可能为空字符串而非NULL，还需追加
AND LEN(TRIM(v.contact_value)) > 0 - 避免在
VALUES里写子查询或函数调用，否则执行计划可能退化为嵌套循环
UNPIVOT遇到NULL和数据类型不一致时的坑
UNPIVOT底层会把所有源列强制转成同一数据类型（取兼容性最高的那个），比如mobile是VARCHAR(20)、email是VARCHAR(100)，最终全转成VARCHAR(100)；但如果其中一列是INT，就会隐式转成VARCHAR，再被UNPIVOT统一处理——这常导致后续CAST失败或精度丢失。
常见报错：
-
Error converting data type varchar to int：出现在UNPIVOT后接CAST(... AS INT)时 -
The type of column "xxx" conflicts with the type of other columns specified in the UNPIVOT list：列类型差异过大，SQL Server无法自动提升 - 结果中出现意外空行：源列含NULL，但没加
WHERE过滤，而你误以为UNPIVOT已帮你剔除了
存储过程中封装列转行逻辑要注意什么
在CREATE PROCEDURE里做列转行，重点不是语法怎么写，而是中间结果怎么传、要不要建临时表。
推荐做法：
- 直接在主查询里用
CROSS APPLY VALUES，避免先塞进#temp再查——临时表会触发重编译、拖慢首次执行 - 如果列转行后要JOIN大表，别用
@table_var存结果：SQL Server对表变量基数估算恒为1，极易选错Nested Loop计划 - 若需动态列名（比如按业务线拼出不同字段），必须用动态SQL，但
EXEC sp_executesql前务必校验输入参数，防注入 - 别在循环体里反复定义同一个
CROSS APPLY逻辑——看着简洁，实则每次迭代都重复解析，不如提成CTE（但注意CTE不缓存，只用一次）
最易被忽略的是NULL处理边界和类型隐式转换链——这两处不出错则已，一错就是线上报表数据对不上。
