动态行转列需元数据驱动拼接+动态执行，必须用存储过程或应用层；SQL Server中QUOTENAME防列名含特殊字符报错；MySQL/PostgreSQL无PIVOT，须用CASE或应用层拼SQL；sp_executesql比EXEC更安全。
动态行转列不是“写一条 SQL 就能跑通”的事，它本质是元数据驱动的字符串拼接 + 动态执行，必须用存储过程或应用层完成；直接在普通查询里硬套 PIVOT 或 CASE 都做不到“自动适配新值”。
SQL Server 里拼 @cols 时漏掉 QUOTENAME 会直接报错
动态列名来自数据（比如 SELECT DISTINCT status FROM orders），一旦值含空格、连字符、中文或数字开头（如 2024-Q3），不加 QUOTENAME 就会崩：
-
IN (2024-Q3, in progress)→ 语法错误：缺少逗号或意外符号 -
IN ([2024-Q3], [in progress])→ 正确，QUOTENAME自动加方括号并转义 - 若目标列名本身是关键字（如
order、user），QUOTENAME同样兜底 - 别手写
'[' + status + ']'—— 碰到单引号（如O'Reilly）就炸，QUOTENAME内置处理
MySQL / PostgreSQL 没有 PIVOT，别白费劲去查语法
执行 SELECT * FROM t PIVOT (...) 在 MySQL 8.0、PostgreSQL 15 或 SQLite 里一律报错：syntax error at or near "PIVOT"。必须换思路：
- 固定列数：用
CASE WHEN ... THEN ... END+SUM()/MAX()，每列一行，手动写死 - 动态列数：放弃纯 SQL，改用应用层（Python/Java）查出唯一值列表，拼成完整 SQL 字符串再执行
- PostgreSQL 可选
crosstab()，但要求提前声明返回结构（RETURNS TABLE(...)），且必须先CREATE EXTENSION tablefunc - MySQL 8.0+ 可用
JSON_OBJECTAGG返回{"Jan":1200,"Feb":950}，适合前端解析，不是宽表
动态拼 SQL 时，EXEC sp_executesql 比 EXEC(@sql) 更安全
拼出来的 @sql 字符串如果含用户输入（比如前端传的表名、字段名），直接 EXEC(@sql) 是高危 SQL 注入点；sp_executesql 支持参数化：
- 错误写法：
SET @sql = 'SELECT * FROM ' + @table_name; EXEC(@sql)—— @table_name 被篡改为orders; DROP TABLE users--就完蛋 - 正确姿势：把可变部分全塞进参数，
sp_executesql只负责执行带占位符的模板，数据库引擎自动隔离 - 注意：
sp_executesql不能传表名、列名、数据库名——这些仍需拼进字符串，但至少 WHERE 条件、值类参数可参数化 - 拼完务必先
PRINT @sql或用SELECT @sql看一眼，避免多一个逗号或少一个括号导致整个 EXEC 失败
真正麻烦的从来不是怎么写那几行 CASE，而是谁来维护列名列表、谁来感知新值出现、谁来决定 NULL 值填 0 还是留空、以及拼 SQL 时那一堆引号和括号嵌套有没有漏掉——这些逻辑一旦散落在多个地方，比性能问题更早把你拖垮。
