SQL Server中动态SQL是实现动态PIVOT的唯一可行方法，因其IN子句不支持变量或子查询，需先查出列名、拼接字符串并用sp_executesql执行，同时注意防注入和结构不可预测性。
SQL Server里用动态SQL拼PIVOT语句是唯一可行路径
SQL Server原生支持PIVOT，但它的IN子句不接受变量或子查询——必须写死列名。想让“产品列表”随数据自动扩展，就得在存储过程中先查出所有要转的值，再拼成字符串执行。硬编码PIVOT (SUM(amount) FOR product IN (Laptop, Mouse, Keyboard))只适用于静态报表，一加新品就报错。
- 先用
SELECT DISTINCT product FROM sales拿到所有产品名，注意去空、去NULL、加单引号和逗号 - 用
STRING_AGG()（SQL Server 2017+）或FOR XML PATH('')（旧版本）拼接成'Laptop','Mouse','Keyboard' - 把拼好的字符串塞进
@sql变量，再用sp_executesql执行——不能用EXEC(@sql)，否则参数化失败 - 别忘了对产品名做
QUOTENAME()处理，防止SQL注入或含空格/特殊字符导致语法错误
MySQL/PostgreSQL用户别找PIVOT关键字，直接放弃
在MySQL 8.0+或PostgreSQL里敲PIVOT，只会收到syntax error at or near "PIVOT"。这两个系统压根没实现这个语法。所谓“动态透视”，本质是动态生成CASE WHEN + GROUP BY组合。你不是在写PIVOT，是在写一段能自动生成SQL的SQL。
- MySQL用
GROUP_CONCAT(DISTINCT CONCAT("MAX(CASE WHEN product = '", product, "' THEN amount END) AS `", product, "`"))构造字段列表 - PostgreSQL用
STRING_AGG()配合format()函数拼CASE分支，注意单双引号嵌套层级 - 拼完后仍需两步：先
PREPARE+EXECUTE（MySQL），或EXECUTE format(...)（PostgreSQL） - 性能上，这种动态拼接比原生
PIVOT多一次元数据查询+字符串处理，千万级表慎用
动态列名导致结果集结构不可预测，应用层必须适配
存储过程返回的列名每次可能不同，比如今天有4个产品，明天新增1个，列数就变5。这意味着：SELECT *在应用里会崩，ORM映射会失败，BI工具刷新元数据时可能卡住。
- 客户端不能依赖固定列序或列名，必须先
SELECT COLUMN_NAME FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME = '##tmp_pivot'（临时表）或解析sp_describe_first_result_set（SQL Server） - 避免把动态PIVOT结果直接INSERT INTO已有结构表；要么建临时表，要么用
OPENROWSET（SQL Server）或dblink（PostgreSQL）绕过结构校验 - 如果只是导出报表，不如在存储过程末尾
SELECT 'product_list' = @cols额外输出一栏，让前端按需渲染
聚合函数选错会让NULL变成0，掩盖真实缺失
用SUM(CASE WHEN ... THEN amount ELSE 0 END)看着简洁，但某客户根本没买过Mouse时，它返回0而不是NULL——这在漏斗分析里等于把“未发生行为”当成“行为值为0”，后续计算转化率全错。
- 正确写法是
SUM(CASE WHEN product = 'Mouse' THEN amount END)，省略ELSE分支，让结果保持NULL - 若必须转0，用
COALESCE(SUM(...), 0)显式转换，逻辑清晰且可审计 -
MAX()或MIN()在单值场景下更安全，比如取每个客户的最高单笔订单额，不会因NULL干扰聚合范围
动态拼SQL这事，表面是语法问题，实际是数据契约问题：你没法既保证列名动态，又维持结果集稳定。真要兼顾灵活性和健壮性，得在存储过程外加一层元数据管理——比如把“哪些产品该参与透视”存在配置表里，而不是每次都从销售明细里扫一遍。
