SQL Server存储过程不能直接接收视图作为参数，仅支持标量类型和用户定义表类型（TVP）；需先查询视图结果并传入TVP，临时表方案存在作用域、并发与维护风险。
SQL Server 中存储过程不能直接接收视图作为参数
不能。SQL Server 的存储过程不支持把视图（或表、临时表等结果集）当作参数传入——CREATE PROCEDURE 允许的参数类型只有标量类型（如 INT、VARCHAR、DATETIME）和用户定义表类型（UDT），而视图本身不是数据容器，只是封装了 SELECT 语句的逻辑对象。
常见误解是以为“视图像表一样能被引用”，但实际调用时仍需通过名称解析，无法在运行时动态绑定为参数值。
- 试图写
CREATE PROC myproc @v VIEW会直接报错：Incorrect syntax near 'VIEW' -
EXEC myproc @v = 'my_view'也不行——字符串只是名字，不是可传递的数据结构 - 即使使用动态 SQL，传入的也只是视图名，不是视图内容；真正执行仍需拼接并
EXEC或sp_executesql
替代方案：用表值参数（TVP）传递视图查询结果
如果目标是把视图输出的数据交给存储过程处理，正确做法是先查出视图结果，再以表值参数形式传入。前提是提前创建好匹配结构的用户定义表类型。
例如，视图 v_active_users 返回 id INT, name NVARCHAR(50)，则需先建：
CREATE TYPE dbo.ActiveUserTableType AS TABLE (
id INT,
name NVARCHAR(50)
);
然后在调用端（如 C# 或 T-SQL 批处理）填充数据并传入：
DECLARE @tvp AS dbo.ActiveUserTableType; INSERT INTO @tvp SELECT id, name FROM v_active_users WHERE status = 'active'; EXEC myproc @user_data = @tvp;
- TVP 是唯一原生支持“传入多行数据”的方式，性能优于字符串拼接或临时表
- 必须显式声明类型，且列名、顺序、可空性都要与 TVP 定义一致，否则报错
The table-valued parameter ... must be declared with a user-defined table type - 不能在 TVP 中直接引用视图名；必须先
INSERT ... SELECT把数据捞出来
为什么不用临时表或全局临时表“曲线救国”？
有人尝试在调用前建 #temp，插入视图数据，再让存储过程读取——这看似可行，但隐患明显：
- 本地临时表
#temp在存储过程内不可见（作用域限于当前批处理） - 全局临时表
##temp虽可跨会话访问，但引发并发风险：多个用户同时执行可能覆盖彼此数据 - 存储过程中硬编码
SELECT * FROM ##temp会让依赖关系隐晦，难以维护和测试 - 没有类型校验，列缺失或类型不匹配要到运行时报错，比如视图改了字段但存储过程没同步
相比之下，TVP 强类型、作用域清晰、可复用，是更可控的选择。
PostgreSQL / MySQL 用户注意语法差异
这个问题在其他数据库里表现不同，但核心限制类似：
- PostgreSQL 不支持任何“表参数”，连 TVP 都没有；常用方案是传
REGCLASS（表/视图 OID）+ 动态 SQL，或改用函数返回SETOF类型 - MySQL 根本不支持自定义复合参数类型，只能靠临时表 + 命名约定（如强制要求调用方建
tmp_input），或把视图逻辑复制进存储过程内部 - 所有方案都绕不开一个事实：视图不是值，它不携带数据，只携带查询逻辑——真正传递数据，终究得靠结果集落地
最容易被忽略的是权限问题：即使用了 TVP，如果视图底层涉及跨库查询或视图定义中用了 WITH CHECK OPTION，调用者仍可能因缺少 SELECT 权限而失败，而不是参数错误。
