sql server视图不支持参数，必须用内联表值函数（itvf）替代，其语法为create function...returns table as return (select...)，支持参数、可join、能被优化器内联，性能接近视图。
SQL Server 用 ITVF 替代带参视图
直接写 CREATE VIEW v(@p) 会报错 Msg 102, Level 15, State 1: Incorrect syntax near '@' —— 视图语法根本不接受参数。必须换用内联表值函数（ITVF），它能被优化器内联展开，性能几乎等同视图。
- ✅ 正确写法：
CREATE FUNCTION dbo.orders_by_status(@status NVARCHAR(20)) RETURNS TABLE AS RETURN (SELECT * FROM orders WHERE status = @status) - ❌ 避免多语句 TVF：
RETURNS @t TABLE(...)+INSERT INTO @t，会导致中间结果物化，JOIN 时执行计划崩坏 - 调用方式和视图一样：
SELECT * FROM dbo.orders_by_status('shipped')，还能参与JOIN、WHERE下推 - 注意：ITVF 中不能用
TOP @n，需改用OFFSET 0 ROWS FETCH NEXT @n ROWS ONLY
PostgreSQL 用 SETOF 函数模拟参数化视图
PostgreSQL 的 CREATE VIEW 同样不支持参数，但 CREATE FUNCTION ... RETURNS SETOF table_name 是事实标准替代方案。关键在语言选 sql 而非 plpgsql，否则优化器无法下推 WHERE 条件。
- ✅ 安全写法：
CREATE FUNCTION users_in_dept(dept_id INTEGER) RETURNS TABLE(id INTEGER, name TEXT) LANGUAGE sql AS $$ SELECT id, name FROM users WHERE dept_id = $1 $$; - ❌ 错误写法：
LANGUAGE plpgsql+RETURN QUERY SELECT ...，函数变成黑盒，WHERE age > 30无法下压到users表 - 函数名会被当表名用：
SELECT * FROM users_in_dept(5)，但列名必须显式声明，否则调用侧看到的是原始字段名而非别名 - 权限要收紧：
REVOKE EXECUTE ON FUNCTION users_in_dept(INTEGER) FROM PUBLIC，再按角色授权
MySQL 怎么办：没有原生表值函数
MySQL 8.0+ 仍不支持返回结果集的函数，硬套视图传参只会触发语法错误 ERROR: syntax error at or near "("。此时只能退到应用层或变通方案，没有数据库级干净解。
- 最稳做法：应用拼 SQL，如
SELECT * FROM orders WHERE status = ?，但得自己防注入、管缓存、处理权限 - 折中方案：建带固定条件的视图（如
v_orders_shipped），靠多个视图覆盖常用参数组合，缺点是维护成本高、无法动态组合 - 危险方案：用预处理语句 +
PREPARE/EXECUTE模拟，但每次执行都绕过查询缓存，且 DBA 无法审计完整逻辑链 - 注意：MySQL 的
IFNULL和 PostgreSQL 的COALESCE对空字符串处理不同，跨库迁移时字段逻辑容易错位
为什么别硬改视图定义来“模拟”参数
有人试过在视图里写 WHERE status = COALESCE(@status, status) 或依赖 CURRENT_USER()，结果发现根本不可靠——这些值在视图编译期就固化了，运行时不会刷新，且不同会话间行为不一致。
- 视图定义一旦创建，
SELECT语句就锁定，所有参数占位符（如@var）在解析阶段就被当作未声明变量报错 - 用
SET @p = 'shipped'; CREATE VIEW v AS SELECT * FROM orders WHERE status = @p看似可行，但下次会话里@p为空，视图查不到数据，DBA 也无法定位问题源头 - 真正需要复用逻辑时，函数封装是唯一可控路径；视图只适合定义静态口径，比如统一 “活跃用户” 计算规则，而不是做查询路由
函数的列定义和类型必须和返回结果严格一致，漏掉一个 RETURNS TABLE(id INT, name TEXT) 就会让下游应用报 column "name" does not exist —— 这种错不会在创建时暴露，只在调用时炸。
