SQL视图本身不支持参数传递，这是SQL标准的硬性限制；应改用SQL Server的内联表值函数（ITVF）或PostgreSQL的RETURNS TABLE函数替代，二者均支持参数、可优化器内联、能JOIN和WHERE下推。
SQL 视图本身不支持参数传递，这不是版本或权限问题，而是 SQL 标准层面的硬性限制——CREATE VIEW 语句里出现 @param、$1 或 ? 都会直接报错，比如 Incorrect syntax near '@'（SQL Server）或 syntax error at or near "$"（PostgreSQL）。
SQL Server 中用内联表值函数（ITVF）替代视图
这是最接近“带参视图”的方案，语法简洁、可被优化器内联、能 JOIN、能 WHERE 下推，性能几乎和手写 SQL 一致。
-
CREATE FUNCTION必须用RETURNS TABLE AS RETURN (SELECT ...)形式，不能有BEGIN...END、DECLARE或流程控制 - 参数必须声明类型，如
@dept_id INT，且只能是标量类型 - 调用时必须加括号：
SELECT * FROM dbo.fn_users_by_dept(5)，不加括号会报错“对象名无效” - 避免在函数体中使用
GETDATE()、NEWID()等非确定性函数，否则无法被索引视图引用，也可能导致执行计划缓存失效
示例：
CREATE FUNCTION dbo.fn_users_by_dept(@dept_id INT)
RETURNS TABLE
AS
RETURN (
SELECT id, name, email
FROM users
WHERE dept_id = @dept_id AND is_active = 1
);PostgreSQL 中用 RETURN SETOF 或 RETURNS TABLE 函数
PostgreSQL 原生支持返回结果集的函数，行为与 SQL Server 的 ITVF 类似，但语法和优化细节不同。
- 推荐用
RETURNS TABLE(...)+RETURN QUERY，比RETURN NEXT更清晰、更易维护 - 默认函数稳定性为
STABLE；若函数体含子查询或依赖会变的数据（如NOW()），需显式声明VOLATILE，否则可能被错误缓存 - 想在
JOIN中使用时，记得加LATERAL（例如FROM orders o JOIN LATERAL get_order_items(o.id) i ON true），否则会报错“cannot reference column from outer query” - 不建议用
EXECUTE format(...)拼接动态 SQL，那会绕过查询计划缓存，也容易引入注入风险
示例：
CREATE OR REPLACE FUNCTION users_in_dept(dept_id INTEGER)
RETURNS TABLE(id INTEGER, name TEXT, email TEXT) AS $$
SELECT id, name, email
FROM users
WHERE users.dept_id = $1 AND is_active;
$$ LANGUAGE sql STABLE;MySQL 为什么没有真正等价物？
MySQL（包括 8.0.33）仍不支持返回表的函数，CREATE FUNCTION 只能返回单个标量值。所谓“TABLE 函数”仅限于 TABLE 语句语法糖，不能接受参数。
- 常见误操作：在存储过程中用
PREPARE+EXECUTE拼出完整SELECT并执行——它能跑通，但结果集无法被其他 SQL 引用，不能出现在FROM子句，也不能JOIN - 可行折中：建一个宽视图（包含所有常用过滤字段），把
WHERE逻辑交给应用层或上层存储过程，例如视图保留status、created_at、tenant_id，由调用方决定加哪些条件 - 如果必须参数化且要复用，只能靠应用层拼接 SQL，或升级到 MariaDB 10.11+（支持类似 PostgreSQL 的
RETURN TABLE函数）
为什么别用多语句表值函数（MSTVF）或存储过程模拟？
它们看起来更灵活，但代价是隐性的：执行计划不可预测、统计信息丢失、JOIN 性能断崖下跌，尤其在数据量超过万行后表现明显。
- MSTVF（SQL Server）内部用
DECLARE @t TABLE+INSERT INTO @t，优化器无法展开，会当成黑盒处理，常强制嵌套循环 - 存储过程即使返回结果集，也不能出现在
FROM子句里，SELECT * FROM EXEC sp_get_users 5是语法错误 - 用字符串拼接 +
EXEC()创建临时视图，只在当前会话有效，其他连接看不见，且每次执行都重新编译，毫无复用价值
真正的“参数化视图”需求，本质是在要求一个**可组合、可优化、可重用的参数化查询封装**——只有内联表值函数（SQL Server / PostgreSQL）或等效机制（如 MariaDB 的表函数）能满足全部条件。其他方案都是权衡取舍，不是替代，而是降级。
