存储过程不能直接返回动态列结构，因其编译时已锁定输出列名和类型；需由应用层拼SQL并调用存储过程做校验与事务封装，数据库仅负责执行结构固定的查询。
存储过程本身不能直接“返回动态列结构”给前端报表，它只能返回固定结构的结果集；真正要支持前端动态报表，得靠外部机制配合——比如用内联表值函数（SQL Server）、视图+WHERE过滤（MySQL）、或由应用层拼SQL再调用存储过程做校验与事务封装。
为什么存储过程不能直接返回动态列
SQL Server 和 MySQL 的存储过程在编译时就锁定了输出列名和类型，SELECT * FROM @table 或 PIVOT (SUM(x) FOR col IN (@cols)) 这类写法会直接报错。即使你用 sp_executesql 或 PREPARE/EXECUTE 动态执行查询，结果集结构也无法被客户端（如 FineReport、PowerBuilder DataWindow）在设计期识别——它们需要明确字段名才能绑定控件。
- 前端报表工具（如 FineReport、PB、Tableau）依赖元数据获取列信息，而存储过程不提供稳定元数据
- 动态列场景（如按科目展开、按日期分组）必须先查出列名列表，再拼新 SQL，这步不能在存储过程中完成并“返回给前端”
- 试图用
INSERT INTO #tmp EXEC @sql再 SELECT * FROM #tmp，只是把动态结果转成静态结构，但列名仍是运行时才知道，前端仍无法预知
SQL Server：用内联表值函数替代存储过程
如果你的前端需要“像查表一样调用带参逻辑”，CREATE FUNCTION ... RETURNS TABLE 是唯一正解。它支持参数、可被 JOIN、执行计划复用，且字段结构在定义时即固定（哪怕内部是动态拼接，对外暴露的列必须写死）。
- 函数体只能是一个
SELECT，不能有DECLARE、IF、游标，所有逻辑得用 CTE、CASE、窗口函数展开 - 示例：
CREATE FUNCTION dbo.fn_sales_by_period(@period_type VARCHAR(10)) RETURNS TABLE AS RETURN (SELECT DATEPART(YEAR, order_date) AS year, SUM(amount) AS total FROM orders GROUP BY DATEPART(YEAR, order_date)) - 调用：
SELECT * FROM dbo.fn_sales_by_period('year')，FineReport 或 PB 都能正常识别字段 - 别用多语句表值函数（MTVF），它返回黑盒结果，JOIN 性能极差
MySQL：靠视图 + 应用层拼 WHERE，存储过程只做兜底
MySQL 8.0.29 前不支持返回表的函数，所以没有等价物。可行路径是：建宽表视图（含所有可能用到的维度字段），前端传参决定 WHERE 条件；存储过程只负责校验参数、处理空值、写日志、启事务——不参与列生成。
PigX UI Pro 前端开发指南 - Vue 3 + TypeScript + Element Plus。当用户提到 PigX UI、PigX 前端、lgb-mgui 项目、Vue 3 企业级后台开发、Element Plus 后台开发时使用此技能。
立即学习“前端免费学习笔记（深入）”；
- 视图字段必须显式列出，不能
SELECT *，否则加字段后视图失效 - 存储过程里不要尝试
PREPARE/EXECUTE后返回结果集给前端，PB 或 FineReport 无法解析其结构 - 如果前端真要“选哪些列”，让应用层拼完整 SQL（如
SELECT city, sales FROM v_report WHERE region = ?），再调用一个轻量存储过程做权限检查和错误捕获 - 关键字段加索引，如
INDEX idx_region_city (region, city)，避免全表扫描
PowerBuilder 动态 DataWindow 必须绕开存储过程
当 PB 需要根据用户勾选实时生成表格时，DataWindow.Create() 接收的是完整 SQL 字符串，不是存储过程名。你不能写 dw_1.Create("EXEC sp_get_data @p1, @p2")——它只会报错“Invalid SQL statement”。
- 正确做法：在 PB 脚本中拼出最终 SQL（如用
String ls_sql拼"SELECT " + ls_cols + " FROM t WHERE " + ls_where），再传给Create() - 存储过程只用于后台校验（如
EXEC sp_check_param @p1 OUTPUT）或事务操作（如插入配置、更新状态），不参与数据查询输出 - 若需防注入，SQL 拼接前对字段名白名单校验（查配置表
SELECT col_name FROM report_columns WHERE enabled = 1），而非依赖存储过程过滤 - 注意
Modify()调用频繁时容易出错，优先用Create()一次性生成，别反复改
最常被忽略的一点：前端动态报表的“动态”不在数据库层，而在应用层。存储过程的职责是安全、一致、可审计的数据操作，不是猜用户下一步想看哪几列。把列选择逻辑推给前端或中间层，数据库只管把结构固定的 SQL 执行好，才是可持续的方案。
