UNPIVOT必须显式硬编码列名，不支持变量、子查询或通配符；NULL值默认被过滤，列名含特殊字符需用方括号包裹，且须先聚合再转行。
UNPIVOT在SQL Server中必须显式指定列名，不能动态生成
SQL Server的UNPIVOT语法不支持变量或子查询来填充列列表，所有待转行的列必须硬编码写死。比如你有score_math、score_english、score_science三列，就得明确列出：
SELECT name, subject, score FROM scores UNPIVOT (score FOR subject IN (score_math, score_english, score_science)) AS u
常见错误现象：Incorrect syntax near ',' 或 Invalid column name，往往是因为列名拼错、漏括号，或用了保留字（如order、user）没加方括号。
- 列名含空格或特殊字符时，必须用
[score math]包裹 -
UNPIVOT会自动过滤NULL值——如果某行score_english为NULL，那它不会产出对应行 - 若需保留NULL，得先用
ISNULL(score_english, 0)等预处理，但语义可能失真
CROSS APPLY + VALUES适合MySQL/PostgreSQL用户模拟列转行
MySQL没有UNPIVOT，PostgreSQL也没有原生支持，但可以用CROSS APPLY（SQL Server）或等效的LATERAL（PostgreSQL）、JOIN ... ON TRUE（MySQL 8.0+）配合VALUES构造虚拟行集。
例如把users(id, tag1, tag2, tag3)转成(id, tag)：
SELECT u.id, v.tag FROM users u CROSS APPLY (VALUES (u.tag1), (u.tag2), (u.tag3)) AS v(tag) WHERE v.tag IS NOT NULL;
关键点：
- MySQL需改用
JOIN ... ON TRUE+ 子查询，或直接用UNION ALL三段SELECT（更兼容老版本） -
CROSS APPLY天然支持关联外层字段，比如v.tag能直接参与WHERE或JOIN条件 - 性能上，
VALUES方式比相关子查询快，因为避免了重复执行
列转行后JOIN关联，ON条件容易漏掉外层主键
做完列转行，常要和另一张维度表（比如subjects(id, name)）关联。最容易出错的是JOIN时忘了绑定原始主键，导致笛卡尔积或结果膨胀。
错误写法：
SELECT u.id, s.name, v.score FROM users u CROSS APPLY (VALUES (u.math), (u.english)) AS v(score) JOIN subjects s ON s.code = 'math' OR s.code = 'english'; -- ❌ 全表匹配，每行变2×N行
正确写法：
- 用CASE或映射表明确关联逻辑：
JOIN subjects s ON s.code = CASE v.idx WHEN 1 THEN 'math' ELSE 'english' END - 或提前在
VALUES里带上标识：VALUES ('math', u.math), ('english', u.english)，再JOIN subjects s ON s.code = v.code - 别依赖ORDER隐含顺序——
VALUES不保证行序，必须显式带标识字段
Oracle用UNPIVOT时，NULL值默认被排除，且不支持聚合嵌套
Oracle的UNPIVOT默认行为是INCLUDE NULLS可选，但多数人没加，结果发现数据少了——其实不是少，是NULL被跳过了。
示例：
SELECT * FROM sales UNPIVOT INCLUDE NULLS (amount FOR quarter IN (q1,q2,q3,q4));
注意：
- 不加
INCLUDE NULLS，q2为NULL的行不会产出quarter='q2'记录 -
UNPIVOT不能直接套SUM()或MAX()，想先聚合再转行？得先CTE或子查询完成聚合，再UNPIVOT - 如果列名来自动态元数据（比如用户自定义字段），
UNPIVOT完全无能为力，只能拼SQL或换应用层处理
真正麻烦的从来不是语法本身，而是列转行之后，那个“行”到底代表什么业务含义——它是否还具备唯一性？是否要参与去重或分组？这些逻辑一旦模糊，JOIN出来的结果就不可信。
