简介：SQL Server中实现行转列是报表查询常见的刚需，这份66KB的PDF文档面向需要编写透视查询的数据库开发与数据分析人员。内容围绕店铺一周收入表WEEK_INCOME展开，先给出传统CASE WHEN配合SUM的写法，再重点讲解SQL Server 2005及以上版本提供的PIVOT运算符，通过建表、插入模拟数据、逐步拆解SUM(INCOME) FOR [WEEK] IN (...)等语法要点，并对比两种写法的优缺点，帮助读者理解如何把星期列的值转为七个结果列。文档也说明UNPIVOT的逆向思路，以及动态列、大量行这类场景下PIVOT的局限与替代方案。全文以真实示例贯穿，文末还给出了MSDN官方文档和参考博文链接，便于继续深入学习。整个资源为1个PDF文件，压缩包约66KB，短小精悍，适合随时查阅与对照练习；已有1530人浏览学习。跟随文中完整示例，读者能快速掌握PIVOT的书写套路，在制作周报、收入汇总等数据透视需求时少走弯路。
1. 行转列这件事，为什么 PIVOT 才是 SQL Server 的正解
行转列这件事，很多人的第一反应是写一堆 CASE WHEN 再套 GROUP BY；等列数涨到几十个、维度从月份换成地区再换成渠道，那套 SQL 就成了没法维护的缝合怪。月底做经营分析时，业务方要的是把每个产品线近 12 个月的销售额，从「一行一个月」的明细表变成「一行一个产品线、12 个月各占一列」的宽表——这正是 SQL Server 里 PIVOT 运算符的主场。
PIVOT 是 SQL Server 从 2005 年就内置的行转列运算符，专门解决「把某一列的值展开成多列，同时聚合另一列」这组需求。它不是黑科技，但会用的人不多：多数教程只讲语法，不讲选型边界，结果读者在真实表上一跑就翻车——内层多带一列导致隐式分组拆行、日期格式匹配不上、动态列顺序乱掉，都是高频事故。
这篇笔记把 PIVOT 的透视逻辑、静态与动态写法、性能边界和五个高频坑一次讲透，末尾附一个用 UNPIVOT 对拍验证宽表的方法。适合写报表 SQL 的从业者，也适合被 CASE WHEN 套娃折磨到想重构的维护者。
2. PIVOT 的语法骨架：透视三要素与第一个能跑的查询
2.1 透视逻辑的核心三要素：聚合函数、分组列、展开列怎么选
PIVOT 的语法看起来唬人，拆开之后其实就三件事：决定每个格子填什么数、决定哪些列的值要变成结果集的列、决定结果集按什么维度一行行排。第一件事由聚合函数决定，第二件事由 FOR 子句和 IN 列表决定，第三件事由 SELECT 里剩下的列决定。标准写法如下：
SELECT <分组列>, <展开值1>, <展开值2>, ... FROM ( SELECT <分组列>, <展开列>, <聚合列> FROM 数据源 ) AS 内层别名 PIVOT ( <聚合函数>(<聚合列>) FOR <展开列> IN (<展开值1>, <展开值2>, ...) ) AS 透视别名;分组列是最容易被忽略的要素。很多人以为 PIVOT 只按 SELECT 里「看起来像分组」的列分组，实际上它的规则是：内层查询输出、且没有出现在 FOR 子句和聚合函数里的所有列，都会被隐式当作分组键。换句话说，只要内层 SELECT 多带一列，比如把渠道带出来，结果集就会按「产品线 + 渠道」的组合拆成多行，而不是按产品线聚成一行。这也是后面避坑章节里排第一位的翻车现场。
提示：内层派生表多选一列，PIVOT 就多一个隐式分组键。新手最容易在这里踩坑，而且从执行计划上看不出任何异常。
展开列的选择有一条原则：这个列的取值集合必须有限、可枚举，而且每个值在业务上有独立成列的意义。月份、地区、渠道、状态值都合适；而订单号、流水号这类高基数列，一旦放进 FOR，结果集会变成几百上千列，没有任何实用价值。另外，一个 PIVOT 只能处理一个 FOR 列。想把「月份和渠道」同时展开成二维矩阵，SQL Server 的 PIVOT 做不到，常见做法是嵌套两层 PIVOT，或者干脆放弃，改用报表工具的矩阵渲染。
聚合函数的选择上，SUM、COUNT、AVG、MAX、MIN 都能用，但语义差异要分清。SUM 会忽略 NULL，可如果某组合压根没有行，PIVOT 不会补一行，而是让这个格子不存在；MAX/MIN 常用于「取该组在某个展开值下的文本或状态」，比如把标签列展开成布尔标记；COUNT(*) 统计行数，COUNT(聚合列) 统计非空值个数，两者在透视场景下结果可能完全不同。
2.2 最小可运行示例：把月份转成列，用三行数据看清 PIVOT 的行为
假设有一张销售明细表，结构是产品线、销售月份、销售额。我先建一个最小数据集：
CREATE TABLE 销售明细 ( 产品线 NVARCHAR(20), 销售月份 DATE, 销售额 DECIMAL(12,2) ); INSERT INTO 销售明细 VALUES ('产品A', '2024-01-01', 12000), ('产品A', '2024-02-01', 15000), ('产品B', '2024-01-01', 8000), ('产品B', '2024-03-01', 9500);注意销售月份我建成了 DATE 类型。这是个真实的坑点：如果直接用 '2024-01' 这种字符串和 DATE 列比较，SQL Server 会做隐式转换，多数情况下能跑，但一旦涉及索引或排序，行为就不可控。所以下面的透视查询里，我先在内层把它转成可比较的字符串，避免类型问题。现在把 1 到 3 月的销售额转成列：
SELECT 产品线, [2024-01] AS 一月, [2024-02] AS 二月, [2024-03] AS 三月 FROM ( SELECT 产品线, CONVERT(NVARCHAR(7), 销售月份, 120) AS 月份文本, 销售额 FROM 销售明细 WHERE 销售月份 BETWEEN '2024-01-01' AND '2024-03-31' ) AS 源数据 PIVOT ( SUM(销售额) FOR 月份文本 IN ([2024-01], [2024-02], [2024-03]) ) AS 透视结果;CONVERT 的第三个参数 120 表示 ODBC 规范格式，输出 YYYY-MM，正好把 DATE 转成「年-月」的字符串。PIVOT 的 IN 列表用的是 [2024-01] 这种带方括号的写法，因为 2024-01 以数字开头，直接写会触发语法错误，方括号等于显式告诉解析器这是一个列名。执行结果如下：
| 产品线 | 一月 | 二月 | 三月 |
|---|---|---|---|
| 产品A | 12000.00 | 15000.00 | NULL |
| 产品B | 8000.00 | NULL | 9500.00 |
这个结果里有两个细节值得停下来看。第一，产品B 没有 2 月的数据，PIVOT 不会给它补 0 或补 NULL 行，而是直接在二月这个格子上放 NULL；如果你想要 0，得在 PIVOT 之后用 ISNULL 再包一层。第二，内层派生表必须有别名（AS 源数据），PIVOT 本身也必须带别名，这是语法硬性要求，少一个就报错。
再补一个常见的误用对比。有人会把 WHERE 过滤放在 PIVOT 外层，例如先全表透视再过滤产品线。这在几万行的小表上没区别，但数据量上来后，内层过滤能大幅减少聚合的输入行数，执行计划的差异非常明显。我的习惯是：所有能提前的过滤都写进内层派生表，外层 SELECT 只做列别名和排序。
3. 动态 PIVOT：列不确定时用拼接 SQL 自动生成
3.1 为什么静态 PIVOT 撑不住真实业务：每个月改一次 SQL 不是长久之计
静态 PIVOT 的 IN 列表写死，在演示和固定报表里没问题，但真实业务里几乎撑不过三个月。原因很直接：销售月份每个月都会新增，地区可能随时加一个，渠道会从线上扩展到线下。每来一个新值，你就得改一遍 SQL，改完还要重新发布存储过程。更麻烦的是，如果透视结果做成视图，列的变化意味着结果集元数据变化，下游的报表模型、导出模板全部要跟着动。
我见过最典型的场景是这样的：某个报表最初只有 6 个渠道，写死之后跑了大半年，业务方突然说新增了 2 个渠道。负责的开发者把 IN 列表改完，发现数据是对的，但列顺序乱了——新渠道在字符串排序里插到了中间，报表导出模板按原顺序取列，整体错位。这个问题的根源不是改列本身，而是「人肉维护列清单」这件事不可持续。
动态 PIVOT 的思路很简单：先用一条查询把展开列的所有可能值查出来，拼成一个带方括号、以逗号分隔的字符串，再嵌进 PIVOT 的 IN 列表，最后用动态 SQL 执行。这样下次出现新渠道，只需要把数据插进明细表，透视列会自动跟着变，SQL 一行都不用改。
3.2 动态列拼接的标准写法：STRING_AGG 与 FOR XML PATH 两版
SQL Server 2017 及以上版本，拼接列清单最简洁的方式是 STRING_AGG：
DECLARE @cols NVARCHAR(MAX), @sql NVARCHAR(MAX); SELECT @cols = STRING_AGG(QUOTENAME(月份文本), ',') FROM ( SELECT DISTINCT CONVERT(NVARCHAR(7), 销售月份, 120) AS 月份文本 FROM 销售明细 WHERE 销售月份 >= '2024-01-01' ) AS m; SET @sql = N' SELECT 产品线, ' + @cols + N' FROM ( SELECT 产品线, CONVERT(NVARCHAR(7), 销售月份, 120) AS 月份文本, 销售额 FROM 销售明细 WHERE 销售月份 >= ''2024-01-01'' ) AS 源数据 PIVOT ( SUM(销售额) FOR 月份文本 IN (' + @cols + N') ) AS 透视结果 ORDER BY 产品线;'; EXEC sp_executesql @sql;这段代码里 QUOTENAME 的作用是把每个值包上方括号，既满足语法要求，又顺手把特殊字符挡在外面。哪天渠道名里出现空格或引号，不加 QUOTENAME 的拼接会直接报错，甚至产生注入风险。STRING_AGG 的第二个参数是分隔符，这里用逗号，拼出来的 @cols 形如 [2024-01],[2024-02],[2024-03]。字符串里两个连续单引号 '' 是 T-SQL 的转义写法，表示一个普通单引号，因为外层用的是 N'...' 字面量，内部不能再直接写单引号。
如果你的环境还是 SQL Server 2016 或更早，STRING_AGG 不存在，得用 FOR XML PATH 配合 STUFF 模拟字符串聚合：
SELECT @cols = STUFF(( SELECT ',' + QUOTENAME(月份文本) FROM ( SELECT DISTINCT CONVERT(NVARCHAR(7), 销售月份, 120) AS 月份文本 FROM 销售明细 WHERE 销售月份 >= '2024-01-01' ) AS m ORDER BY 月份文本 FOR XML PATH('') ), 1, 1, '');FOR XML PATH('') 会把子查询的每一行结果拼接成一个字符串，STUFF 的作用是去掉开头多出来的那个逗号。注意子查询里必须显式 ORDER BY，否则拼接出来的列顺序取决于物理存储顺序，你无法预测。两者对比，STRING_AGG 更直白，FOR XML PATH 更老但兼容性最好。生产环境如果是混合版本，建议统一用后者，避免一套脚本在两套数据库上行为不一致。
3.3 动态 PIVOT 的参数化：过滤条件别拼进字符串里
动态 SQL 最大的风险不是性能，而是维护和注入。列清单没办法参数化，这是语法决定的，但过滤条件完全可以，而且应该参数化。常见做法是把过滤参数通过 sp_executesql 的第二个参数传入：
DECLARE @start DATE = '2024-01-01'; DECLARE @cols NVARCHAR(MAX), @sql NVARCHAR(MAX); SELECT @cols = STRING_AGG(QUOTENAME(月份文本), ',') FROM ( SELECT DISTINCT CONVERT(NVARCHAR(7), 销售月份, 120) AS 月份文本 FROM 销售明细 WHERE 销售月份 >= @start ) AS m; SET @sql = N' SELECT 产品线, ' + @cols + N' FROM ( SELECT 产品线, CONVERT(NVARCHAR(7), 销售月份, 120) AS 月份文本, 销售额 FROM 销售明细 WHERE 销售月份 >= @start ) AS 源数据 PIVOT ( SUM(销售额) FOR 月份文本 IN (' + @cols + N') ) AS 透视结果;'; EXEC sp_executesql @sql, N'@start DATE', @start = @start;这里有两个 @start，它们不是同一个变量。字符串里的 @start 是 sp_executesql 内部要解析的参数，外层的 @start 是批处理里的变量，通过第三个参数传进去。这种写法有两个好处：一是 WHERE 条件走参数化路径，SQL Server 有机会复用执行计划；二是不用再处理参数值里的单引号转义。列清单那部分仍然只能用字符串拼接，这是 PIVOT 语法的固有边界，接受它就好，不要试图把 IN 列表参数化。
注意：动态 SQL 的列清单无法参数化，过滤条件可以参数化。不要把参数值直接拼进 SQL 字符串。
4. PIVOT 的边界与性能：什么时候该用，什么时候别硬上
4.1 和 GROUP BY + CASE WHEN 对比：两者最终是同一套执行计划
很多从业者对 PIVOT 有误解，以为它是某种专门优化过的黑匣子，性能一定比手写 CASE WHEN 好。我在实际项目里对比过执行计划，结论是：PIVOT 在优化器内部通常会被改写成语义等价的关系代数，也就是按展开列做隐式分组、对每个展开值做条件聚合，和手写 SUM(CASE WHEN ...) 走的是同一条路线。两张表、同数据量、同索引条件下，两者的执行计划和 IO 统计基本一致。
| 对比维度 | PIVOT | GROUP BY + CASE WHEN |
|---|---|---|
| 列清单位置 | 集中在 IN 列表，一眼看全 | 分散在 SELECT 各段表达式 |
| 新增展开值 | 只改 IN 列表 | 要新增整个 CASE 表达式 |
| 动态化 | 拼 IN 列表即可 | 要拼整个 SELECT 列表 |
| 附带计算 | 不方便，需外层再包一层 | 同一层直接算占比、同比 |
| 可读性 | 透视逻辑直观 | 列一多就变成缝合怪 |
手写等价的写法长这样：
SELECT 产品线, SUM(CASE WHEN 月份文本 = '2024-01' THEN 销售额 END) AS [2024-01], SUM(CASE WHEN 月份文本 = '2024-02' THEN 销售额 END) AS [2024-02], SUM(CASE WHEN 月份文本 = '2024-03' THEN 销售额 END) AS [2024-03] FROM ( SELECT 产品线, CONVERT(NVARCHAR(7), 销售月份, 120) AS 月份文本, 销售额 FROM 销售明细 WHERE 销售月份 BETWEEN '2024-01-01' AND '2024-03-31' ) AS 源数据 GROUP BY 产品线;注意这里 CASE WHEN 没有 ELSE，SUM 会自动忽略 NULL，效果和 PIVOT 一致。我的选型标准很简单：如果展开列数量固定、列数不超过十几个，手写 CASE WHEN 可能更好，因为可以在同一层 SELECT 里顺带算占比、同比、排名这些衍生指标；如果展开列数量会增长，或者你想让报表自动适应新维度，就用 PIVOT 并配合动态拼接。关键词是「可维护性」，不是「性能」。你不需要担心 PIVOT 更慢，但也不该期待它更快。
4.2 性能特征与索引建议：先过滤再透视，别让展开列基数爆炸
PIVOT 的执行本质上是在内存或 tempdb 里做一次哈希聚合，开销和输入行数、展开列基数、分组键基数都相关。几个经验参数如下：
| 影响因素 | 建议值 / 做法 |
|---|---|
| 输入行数 | 内层先 WHERE 过滤，行数尽量压到十万级以下再聚合 |
| 展开列基数 | 建议不超过 50～100 个不同值，超过后果断换方案 |
| 分组键基数 | 分组键越多，输出行越多，但聚合压力反而小 |
| 索引 | 建 (展开列, 分组列) INCLUDE (聚合列)，或 (分组列, 展开列) INCLUDE (聚合列) |
| NULL 处理 | 聚合列大量 NULL 时 SUM 自动忽略，行本身不会被丢弃 |
索引选择上，我一般看过滤条件出现在哪一列。如果经常按销售月份过滤，那索引前导列放销售月份，写成 (销售月份, 产品线) INCLUDE (销售额)，让过滤和聚合都走索引；如果经常按产品线查，就倒过来写 (产品线, 销售月份) INCLUDE (销售额)。这里的关键是 INCLUDE 覆盖聚合列，避免回表，否则纯索引扫描也要回表取销售额，IO 翻倍。
另一个容易被忽略的性能问题是展开列基数。假设你把订单状态展开成列，状态只有五六种，没问题；但如果你试图把用户 ID 或订单号展开，结果集会变成几千列宽，每条输出行的行宽大得离谱，排序、网络传输、报表渲染全部遭殃。数据量小的时候看不出问题，记录涨到百万行，查询可能从 2 秒退化到 40 秒。排查手段是看 tempdb 的工作表溢出计数，一旦出现大量溢出，基本可以断定是行宽过大。
我踩过一次这样的坑：某业务方要求按「最近 90 天的每一天」做一列。一开始只有几千行，跑得动；后来数据涨到百万行，查询慢到没法用。最后改成只保留有数据的日期，其余交给报表工具做矩阵渲染，问题才解决。
提示：展开列基数超过 100 个值，PIVOT 大概率不是最优解。宽表不是越宽越好，列宽和查询速度是直接冲突的。
还有一点想提醒：不要对复杂视图直接做 PIVOT。视图里的计算、JOIN 如果被写在透视外层，优化器会把整个视图的中间结果物化到内存再聚合，输入行数完全失控。正确顺序是：先写内层派生表，把过滤、计算、JOIN 都收进去，只输出透视需要的三列。哪一步提前做，都不如这一步重要。
5. PIVOT 使用避坑：五个高频翻车现场与排查思路
5.1 结果比预期多出很多行：透视结果被隐式分组拆散
现象：源表明明只有几个产品线，PIVOT 之后每个产品线却出现多行，行数远大于预期。
原因：内层查询选了多余的列。比如销售明细表里还有区域、渠道两列，你没有在派生表里去掉它们，PIVOT 就把它们当成隐式分组键，按「产品线 + 区域 + 渠道」的组合拆行。
解决：内层派生表只 SELECT 透视需要的三列。
-- 错误：直接拿全表透视，结果按区域、渠道拆散 SELECT 产品线, [2024-01], [2024-02] FROM 销售明细 PIVOT ( SUM(销售额) FOR 月份文本 IN ([2024-01], [2024-02]) ) AS p; -- 还会报错：原表里根本没有 月份文本 这个字段 -- 正确：内层先投影出三列，把多余列全部挡在外面 SELECT 产品线, [2024-01], [2024-02] FROM ( SELECT 产品线, CONVERT(NVARCHAR(7), 销售月份, 120) AS 月份文本, 销售额 FROM 销售明细 ) AS 源数据 PIVOT ( SUM(销售额) FOR 月份文本 IN ([2024-01], [2024-02]) ) AS 透视结果;排查思路：先数输出行数，再用「分组列 + 展开列」做一次 GROUP BY 看有多少组合，对比一下就知道是不是被隐式拆分了。
5.2 报错「列名无效」或语法错误：类型不匹配与方括号缺失
现象：PIVOT 查询一执行就报错，错误信息类似「列名 '2024-01' 无效」或「'2024-01' 附近有语法错误」。
原因：两个常见来源。一是展开列的值以数字开头或含特殊字符，没有加方括号；二是 FOR 列的类型和 IN 列表里的字面量类型不一致，比如 FOR 列是 DATE，而 IN 里写的是 '2024-01' 这种缺日的字符串，SQL Server 做隐式转换后匹配不上。
解决：对展开值统一使用 QUOTENAME 包一层；类型不一致时，先在内层把列转成一致的字符串。
-- 推荐：内层 CONVERT 成 NVARCHAR(7)，IN 列表保持同格式 SELECT 产品线, [2024-01] FROM ( SELECT 产品线, CONVERT(NVARCHAR(7), 销售月份, 120) AS 月份文本, 销售额 FROM 销售明细 ) AS 源数据 PIVOT ( SUM(销售额) FOR 月份文本 IN ([2024-01]) ) AS 透视结果;排查时先把内层查询单独跑一遍，确认展开列的输出值和 IN 列表逐字对上，包括空格和大小写。日期格式这块最容易出隐性 bug：内层输出 '2024-01'，IN 里写着 '2024-1'，看起来一样，实际匹配不上，结果全是 NULL，不报错但数据全丢。
5.3 动态 PIVOT 的列顺序乱：拼接没有排序导致
现象：动态生成的透视结果，列顺序每次执行可能不同，或者新渠道插入到列表中间，导致下游取数错位。
原因：FOR XML PATH 子查询里没有 ORDER BY，STRING_AGG 也没有保证顺序的重载。列顺序实际取决于聚合时的探测顺序，物化后不可控。
解决：在拼接列清单的子查询里显式 ORDER BY。
-- FOR XML PATH 版：子查询内部排序 SELECT @cols = STUFF(( SELECT ',' + QUOTENAME(月份文本) FROM ( SELECT DISTINCT CONVERT(NVARCHAR(7), 销售月份, 120) AS 月份文本 FROM 销售明细 ) AS m ORDER BY 月份文本 FOR XML PATH('') ), 1, 1, '');如果业务要求按自然顺序而不是字母序，比如 1 月、2 月，而不是 1 月、10 月、2 月，那就得在月份表里加一个排序键，ORDER BY 排序键。不要在应用层去猜列的位置，这个坑会让导出模板全面错位，排查成本极高。
5.4 透视结果大量 NULL 且数字对不上：组合缺失与聚合语义
现象：PIVOT 结果里很多格子是 NULL，和业务预期「没有数据就显示 0」不符；或者某些格子算出来的数字比手工核对的小。
原因：PIVOT 只为源数据里实际存在的「分组键 + 展开值」组合生成格子，不存在的组合一律不出现或为 NULL。这是设计，不是 bug。另外，如果聚合列本身含 NULL，SUM 会忽略；如果用 AVG 而源数据有重复行，平均值和手工按明细算的对不上。
解决：确认源组合完备性，然后在外层用 ISNULL 补 0。
SELECT 产品线, ISNULL([2024-01], 0) AS 一月, ISNULL([2024-02], 0) AS 二月 FROM ( SELECT 产品线, 月份文本, 销售额 FROM 销售明细 ) AS 源数据 PIVOT ( SUM(销售额) FOR 月份文本 IN ([2024-01], [2024-02]) ) AS 透视结果;排查时先跑一条 GROUP BY 源表，数每个「产品线 + 月份」组合到底有没有行，再决定是补 0 还是保留 NULL。补 0 的位置建议放在 PIVOT 外层，不要放进内层，否则 NULL 会被当成真实值参与聚合，数字直接翻车。
5.5 动态 SQL 报错难定位：拼接串里引号嵌套失控
现象：动态 PIVOT 存储过程一执行就报语法错误，错误信息指向很靠后的位置，完全看不出是哪段拼接出了问题。
原因：SQL 字符串里多个单引号嵌套，转义符写错一个，整条语句就变成不可解析的文本。尤其是过滤条件里出现中文、单引号、日期格式时，肉眼根本检查不过来。
解决：开发阶段先 PRINT 完整的 @sql，再复制到查询窗口执行，不要直接 EXEC。
-- 调试：先打印，后执行 PRINT @sql; -- EXEC sp_executesql @sql; -- 确认无误后再取消注释提示：动态 SQL 开发阶段先 PRINT 再执行，一次肉眼比对胜过十次报错猜谜。
如果 PRINT 出来的 SQL 长度超过显示上限，改用 SELECT @sql FOR XML PATH，或者直接把 @sql 变量拖进调试器的局部变量窗口看。我在生产环境见过最离谱的一次，是拼接 SQL 里混入了全角单引号，数据库报错提示的行号完全没有参考价值，最后靠 PRINT 逐段肉眼比对才找出来。养成「动态 SQL 必先打印」的习惯，能省掉大量排查时间。
6. UNPIVOT 回来验证：用逆透视对拍宽表有没有写错
PIVOT 做的是行转列，UNPIVOT 做的是列转行。它最大的实用价值不是炫技，而是验证：你辛辛苦苦拼出来的动态宽表，到底有没有把数字弄丢、弄重。我的验证习惯是，宽表生成后，用 UNPIVOT 把它转回窄表，再和源表的 GROUP BY 结果做一次全量对拍。
SELECT 产品线, 月份文本, 销售额 FROM ( SELECT 产品线, [2024-01], [2024-02], [2024-03] FROM 透视结果 ) AS 宽表 UNPIVOT ( 销售额 FOR 月份文本 IN ([2024-01], [2024-02], [2024-03]) ) AS 逆透视;UNPIVOT 有两个和直觉相反的行为，必须提前知道。第一，它不会保留 NULL：源宽表里是 NULL 的列，在逆透视结果里直接没有对应行。所以对拍时不能直接比对行数，而要先用 ISNULL 补 0 再汇总。第二，所有参与 UNPIVOT 的列必须是同一数据类型，否则直接报错；宽表里如果混着金额和数量，得分开做两次 UNPIVOT。
我用这个技巧救回过一次上线事故。当时某个报表的动态 PIVOT 上线后，业务反馈某几列数字整体偏小。我把宽表 UNPIVOT 回窄表，和源表 GROUP BY 对拍，发现差额正好等于「某渠道被内层 WHERE 过滤掉的那部分行」。原因是最初写动态拼接时，列清单的查询条件和内层数据的查询条件不一致——一个过滤了该渠道，一个没过滤。这类问题在报表界面、执行计划里完全看不出来，只有对拍能抓到。
从那以后，凡是动态 PIVOT 上线，我的步骤固定是：先跑源表 GROUP BY 基线，再跑宽表 UNPIVOT 对拍，两个结果集用 EXCEPT 全量比对，零差异才发布。这个习惯帮我挡掉了至少三次列清单和过滤条件不同步的翻车。希望帮到你。
本文还有配套的精品资源，点击获取
矩形求和的工程实现)
