存储过程无法真正创建动态视图，因其不支持参数化且CREATE VIEW禁止变量；应使用内联表值函数（ITVF）实现带参、可JOIN、可重用的“动态视图”，SQL Server推荐此方案，MySQL受限需折中，PostgreSQL则原生支持类似功能。
存储过程本身不能“调用视图”来实现动态视图，它只能 SELECT 视图 + 外层 WHERE；真要参数化、可复用、能被 JOIN 的“动态视图”，得用内联表值函数（ITVF），不是存储过程。
为什么不能在存储过程中“创建动态视图”
视图是静态对象，CREATE VIEW 语句里不允许出现变量、参数或流程控制。你在存储过程中写 EXEC('CREATE VIEW v AS SELECT * FROM t WHERE id = ' + @id)，语法上能执行，但这个视图只在当前会话临时存在（SQL Server 中不持久），且其他会话根本看不见——它不是真正的视图，只是字符串拼接后的一次性执行。
常见错误现象：
- 把 SELECT * FROM myview WHERE status = @p 当成“动态视图调用”，其实只是普通查询过滤，视图本身没变
- 试图在视图定义里直接引用存储过程返回值，比如 SELECT * FROM dbo.sp_get_active_users()，SQL Server 直接报错 Invalid use of a side-effecting operator
- 在 MySQL 中用 PREPARE/EXECUTE 拼出完整 SELECT 并执行，结果无法被其他 SQL 引用（不能 JOIN，不能子查询嵌套）
SQL Server 推荐方案：用内联表值函数（ITVF）替代
ITVF 行为最接近你想要的“带参数的视图”：支持输入参数、可被 SELECT/JOIN 直接调用、执行计划可重用、无副作用。
使用要点：
- 函数体只能是单个 SELECT，不能含 DECLARE、SET、IF、游标
- 所有逻辑必须用 CASE、窗口函数、CTE 或子查询展开
- 示例：CREATE FUNCTION dbo.fn_orders_by_status(@status VARCHAR(20)) RETURNS TABLE AS RETURN (SELECT order_id, user_id FROM orders WHERE status = @status)
- 调用：SELECT * FROM dbo.fn_orders_by_status('shipped') 或 SELECT u.name, o.* FROM users u INNER JOIN dbo.fn_orders_by_status('pending') o ON u.id = o.user_id
- 别用多语句表值函数（MTVF），它返回的是不可优化的“黑盒”，大数据量下性能断崖式下降
MySQL 和 PostgreSQL 怎么办
MySQL（8.0.29 前）根本不支持返回表的函数，所以没有真正等价物。折中方案只有两个：
- 建普通视图，把所有可能的过滤字段都保留，靠外部 WHERE 过滤（例如视图含 status、created_at、is_deleted，应用层决定加哪个条件）
- 存储过程中用 PREPARE + EXECUTE 动态执行，但必须接受它无法被嵌套查询的事实——不能出现在 FROM 子句里
PostgreSQL 更友好：CREATE FUNCTION get_orders_by_status(status TEXT) RETURNS TABLE(order_id INT, user_id INT) AS $$ SELECT order_id, user_id FROM orders WHERE status = $1 $$ LANGUAGE sql;
- 它天然支持 RETURNS TABLE，调用方式和 ITVF 几乎一致
- 需配合 LATERAL 才能在 JOIN 中传参，例如：SELECT u.name, o.* FROM users u, LATERAL get_orders_by_status(u.preferred_status) o
如果非要用存储过程封装查询逻辑，注意这三点
不是推荐路径，但现实中有遗留系统必须这么做。此时重点不是“模拟视图”，而是避免典型坑：
- 不要在存储过程中反复 CREATE VIEW / DROP VIEW，权限、依赖、缓存都会出问题
- 如果真需要运行时生成结果集，优先用临时表：SELECT ... INTO #tmp_result FROM ... WHERE ...，再 SELECT * FROM #tmp_result，但注意作用域仅限当前会话
- 所有外部传入的字段名、表名必须严格校验，防止 SQL 注入——别直接拼 @table_name，先查 INFORMATION_SCHEMA.TABLES 确认存在
- 关键参数差异大（如 @status 取值从 'draft' 到 'archived' 分布极不均）时，记得在 SELECT 末尾加 OPTION (RECOMPILE)，否则参数嗅探会让执行计划失效
