SQL Server 应用内联表值函数（ITVF）替代参数化视图，需用 RETURNS TABLE AS RETURN (SELECT...) 单层结构，避免多语句表值函数；PostgreSQL 用 RETURNS TABLE 函数并正确标注 STABLE/VOLATILE；MySQL 缺乏原生支持，只能折中使用宽视图或 JSON_TABLE。
SQL Server 用内联表值函数（ITVF）替代参数化视图
SQL Server 的 CREATE FUNCTION 支持内联表值函数，它行为最接近你想要的“带参视图”：可被 SELECT、JOIN、WHERE 直接调用，执行计划能展开优化，且不引入额外开销。
常见错误是写成多语句表值函数（MTVF），比如函数体里含 DECLARE @t TABLE、INSERT INTO @t —— 这会让优化器无法下推条件，查询变慢几倍甚至几十倍。
- 必须用
RETURNS TABLE AS RETURN (SELECT ...)单层结构，不能有变量、赋值或控制流 - 参数要显式声明类型，如
@status NVARCHAR(20)，避免隐式转换导致索引失效 - 函数体内不要写
TOP @n，SQL Server 不允许；改用OFFSET 0 ROWS FETCH NEXT @n ROWS ONLY - 调用时别漏掉 schema，例如
SELECT * FROM dbo.orders_by_status('shipped')，否则可能找不到函数
PostgreSQL 用 RETURNS TABLE 函数替代
PostgreSQL 的表函数天然支持参数、可内联、可注释，比视图更灵活。关键不是“能不能用”，而是“怎么声明才让优化器信任你”。
典型坑是忘记函数稳定性标签：STABLE 或 IMMUTABLE。如果函数体里用了 NOW() 或子查询但没声明 VOLATILE，优化器可能错误缓存结果；反之，该标 STABLE 却没标，会导致条件无法下推到 WHERE 子句里。
- 用
LANGUAGE sql而非plpgsql包裹简单查询，后者有启动开销 -
RETURNS TABLE(id INT, name TEXT)必须和SELECT字段顺序、类型完全一致，否则列名会变成原始字段名（如users.id），下游应用报错 - 函数调用语法就是
SELECT * FROM orders_by_status('pending')，可直接JOIN、ORDER BY、LIMIT - 避免在函数里写
ORDER BY+LIMIT组合——它会固化输出顺序，掩盖真实数据分布，分页逻辑应由上层控制
MySQL 怎么办：没有真正表值函数，只能折中
MySQL 8.0.29 之前压根不支持返回表的函数，所谓“参数化视图”只能靠应用层拼 SQL 或存储过程硬扛，但这两者都有硬伤：拼 SQL 易注入，存储过程返回结果集无法被 FROM 引用（不能 JOIN，不能嵌套子查询）。
如果你用的是 MySQL 8.0.29+，可以配合 JSON_TABLE 或预编译语句模拟，但依然不是原生支持，且类型检查弱、调试难。
- 最稳妥方案：建宽视图（包含所有可能过滤字段），把
WHERE逻辑交给应用层，例如视图定义含status、created_at、user_id，应用决定加哪几个条件 - 若必须服务端处理，用存储过程 + 临时表，但注意临时表只在当前会话可见，且不能被其他 SQL 引用
- 拒绝用
PREPARE+EXECUTE动态生成完整SELECT并执行——它只是执行一次，不返回可复用的结果集
为什么不能用存储过程假装“动态视图”
有人在存储过程中写 EXEC('SELECT * FROM orders WHERE status = ''' + @p + '''')，这不是动态视图，只是字符串拼接执行。它既不能被 FROM 引用，也无法参与 JOIN，更没法被 BI 工具或 ORM 自动识别。
另一个常见误解是把普通视图加 WHERE 当成参数化调用，比如 SELECT * FROM v_orders WHERE status = @p —— 这只是过滤已有视图，视图本身仍是静态的，所有行都先查出来再过滤，索引可能失效。
- 存储过程返回结果集 ≠ 可组合的表表达式；它本质是 RPC 调用，不是关系代数操作符
- 试图在视图定义里引用存储过程（如
SELECT * FROM dbo.sp_get_active_users()）会直接报错：Invalid use of a side-effecting operator - 真正需要“可重用、可嵌套、可优化”的参数化逻辑，只有表值函数这一条路
函数签名和调用方式看着简单，但列类型对齐、稳定性声明、执行计划是否可下推，这些细节一旦出错，性能和兼容性问题就藏在上线后。
