标准sql的select子句必须编译期确定列名和数量，而“动态列”需运行时从配置表读取字段名、别名等元数据，硬写死join与select无法应对结构变化；存储过程需先查元数据、校验列名防注入、拼接完整sql字符串，再用execute immediate或sp_executesql执行，且列名、表名等对象名不可参数化，只能拼接。
为什么不能直接用 JOIN + 静态 SELECT 实现“动态列”
因为标准 SQL 的 SELECT 子句必须在编译时确定列名和数量，而“动态列”意味着列来自另一张表的行数据（比如配置表里存了字段名、别名、是否显示），运行时才能知道要查哪几列。硬写死 JOIN 和 SELECT 无法应对列结构变化——改个字段就得改代码，没法复用。
用存储过程拼接动态 SQL 的核心步骤
本质是：查出要展示的列定义 → 拼成合法的 SELECT ... FROM ... JOIN ... 字符串 → 用 EXECUTE IMMEDIATE（Oracle）或 sp_executesql（SQL Server）执行。关键不在“怎么拼”，而在“拼得安全、可维护、不崩”。
- 先查列元数据，例如：
SELECT col_name, alias_name, sort_order FROM report_column_config WHERE report_id = @report_id ORDER BY sort_order - 用循环（T-SQL 用
CURSOR，PL/SQL 用FOR rec IN (...) LOOP）逐行读取，拼col_name AS alias_name到字符串变量中 - 注意给每个拼接项加逗号分隔，但首尾不能多逗号——建议初始化为空字符串，每次拼前判断是否非空，再加
, - 最终完整语句形如：
SELECT t1.id, t1.name, t2.amount AS total_amt FROM main_table t1 JOIN detail_table t2 ON t1.id = t2.main_id
容易踩的坑：SQL 注入与权限问题
如果列名来自用户输入或未校验的配置表，直接拼进 SQL 就等于把 EXECUTE IMMEDIATE 的刀递给别人。哪怕只是字段名，攻击者也能注入 FROM users WHERE 1=1; DROP TABLE config; 这类语句。
- 必须白名单校验列名：只允许字母、数字、下划线，且长度 ≤ 64；用正则或
INSTR/CHARINDEX检查是否含分号、--、/*等危险字符 - 别用
CONCAT或+直接拼参数值，要用参数化方式传值——但注意：**列名、表名、ORDER BY 字段不能参数化**，只能靠校验 - 执行动态 SQL 的账号权限要最小化，不能给
db_owner或DBA权限，否则拼错一句就可能删库
MySQL / PostgreSQL 用户要注意语法差异
MySQL 不支持 EXECUTE IMMEDIATE，得用 PREPARE stmt FROM @sql; EXECUTE stmt; DEALLOCATE PREPARE stmt;，且 @sql 是会话级变量，不能跨连接复用；PostgreSQL 要用 EXECUTE 'SELECT ...' INTO ... 或 RETURN QUERY EXECUTE ...，且函数里拼 SQL 必须用 format() 做占位符转义（比如 format('SELECT %I FROM %I', col_name, table_name)）。
- MySQL 中
GROUP_CONCAT可替代循环拼接，但长度受限（默认 1024），需提前设SET SESSION group_concat_max_len = 1000000; - PostgreSQL 的
format('%I', 'user.name')会自动加双引号并转义，比手拼安全得多 - 所有数据库都禁止在动态 SQL 里直接写
WHERE @filter这种——过滤条件必须走参数，否则又绕回注入风险
真正难的不是拼出那条 SQL，而是确保每次拼出来的语句能通过语法检查、权限检查、性能检查；尤其当列数超 50、JOIN 表超 5 个时，生成的 SQL 很容易触发优化器超时或内存溢出——这时候该考虑前端分步加载，而不是硬扛动态拼接。
