SQL视图不能直接接收参数，因其本质是预定义的SELECT语句，不支持运行时参数；表值函数（TVF）才是支持参数并返回结果集的正确替代方案。
SQL视图能不能直接接收参数
不能。标准 SQL 视图（CREATE VIEW）本质是保存的 SELECT 语句，不支持任何形式的输入参数。你写 CREATE VIEW v_user_by_dept AS SELECT * FROM users WHERE dept_id = ? 是语法错误——? 或 @dept_id 在视图定义里不被允许。
常见错误现象：Incorrect syntax near '@'（SQL Server）、ERROR: syntax error at or near "$"（PostgreSQL）、MySQL 报 Unknown column 'xxx' in 'where clause'（误把变量当字段）。
根本原因：视图在创建时就被解析并绑定元数据，运行时无法动态改写查询逻辑。它不是函数，没有执行上下文。
为什么表值函数（TVF）是更合适的替代方案
表值函数能返回结果集，又支持参数，语义上最接近“带参视图”。但要注意：不同数据库对 TVF 的实现差异很大，别直接套用语法。
使用场景：
- 需要按用户 ID 动态查订单历史（
get_orders_by_user(@user_id)） - 多租户系统中根据
tenant_id过滤日志表 - 报表前端传参后生成聚合结果，且需复用逻辑
关键差异点：
- SQL Server 支持内联 TVF（
RETURNS TABLE AS RETURN (SELECT...)），性能接近视图；多语句 TVF 会物化中间结果，慎用 - PostgreSQL 用
RETURN SETOF table_name+RETURN QUERY，参数可直接进WHERE - MySQL 不支持真正意义上的表值函数（8.0+ 有
TABLE函数但限制多），得用存储过程 + 临时表或直接拼接应用层 SQL
简单示例：SQL Server 内联表值函数替代参数化视图
这是最轻量、最安全的做法，编译器能自动内联展开，执行计划和手写 SQL 几乎一致。
CREATE FUNCTION dbo.v_users_by_status (@status VARCHAR(20))
RETURNS TABLE
AS
RETURN (
SELECT id, name, created_at
FROM users
WHERE status = @status AND deleted = 0
);调用方式和视图一样自然：
SELECT * FROM dbo.v_users_by_status('active');
注意：
- 函数名必须带 schema（如
dbo.），否则调用时报Invalid object name - 不能在函数体里用
GETDATE()等非常量函数（SQL Server 内联 TVF 限制），否则被迫降级为多语句 TVF - 别给参数起和列名一样的名字（如
@id和表里id字段），容易引发歧义
容易被忽略的兼容性与权限坑
视图能跨库引用，但大多数 TVF 默认只能访问本库对象。想跨库查，SQL Server 要显式写 other_db.schema.table；PostgreSQL 需要 search_path 配置或全限定名。
权限方面：用户执行 TVF 时，检查的是调用者对底层表的权限，不是函数创建者的权限（即默认是 EXECUTE AS CALLER）。如果用视图+同义词绕过权限控制，换成 TVF 后可能突然报 SELECT permission denied。
还有个隐蔽点：ORM 框架（如 Entity Framework、Django ORM）通常不识别 TVF，不能像视图那样直接映射成模型。你得手动写原生查询或注册为数据库函数。
真要复用复杂逻辑又兼顾 ORM 友好，不如把条件逻辑收口到应用层，数据库只暴露无参视图 + 带索引的过滤字段。
