SQL视图无法参数化是数据库引擎的底层限制，因其为静态DDL快照，不支持运行时变量、非确定性函数或作用域穿透；应使用内联表值函数（ITVF）替代，并在外层查询中实现动态过滤。
SQL 视图本身无法参数化，任何试图在 CREATE VIEW 中塞入 @param、GETDATE() 或拼接列名的操作，都会失败或产生不可靠结果——这不是写法问题，是数据库引擎的底层限制。
为什么直接在视图里写 WHERE status = @status 会报错
SQL Server 报 Must declare the scalar variable "@status"；PostgreSQL 直接语法报错 syntax error at or near "("；MySQL 虽可能创建成功，但 @status 是会话变量，未显式赋值时为 NULL，导致过滤恒不成立。视图定义阶段不参与运行时上下文，没有变量作用域，所有“参数”都是非法符号。
- 视图是 DDL 创建的静态查询快照，不是函数或过程，不接受输入
-
GETDATE()、NOW()、NEWID()等非确定性函数被多数数据库禁止出现在视图WHERE中（SQL Server 明确拒绝，MySQL 行为依赖算法和版本） - 硬编码
WHERE created_at > '2024-01-01'看似能用，但会绑架所有下游查询，丧失按需查历史的能力
用内联表值函数（ITVF）替代：最接近“参数化视图”的正解
它支持参数、可被优化器展开、性能接近视图、语法干净，且在 SQL Server 和 PostgreSQL 中原生可用（MySQL 不支持返回表的函数，需换方案）。
- SQL Server 示例：
CREATE FUNCTION dbo.fn_orders_by_status(@status VARCHAR(20)) RETURNS TABLE AS RETURN (SELECT * FROM orders WHERE status = @status);
- 调用方式：
SELECT * FROM dbo.fn_orders_by_status('shipped')，可直接JOIN、可被外层WHERE下推 - 必须是单个
SELECT，不能有BEGIN...END、变量赋值或控制流 - 避免在函数体中用
GETDATE()：会导致执行计划不稳定，且无法用于索引视图
动态租户过滤：别信 USER_NAME()，用 SESSION_CONTEXT
想让视图自动按当前租户过滤？USER_NAME() 只返回登录账号，无法表达业务租户 ID。真正可控的是应用层设置的 SESSION_CONTEXT，但它极易因未设值或残留导致崩溃。
- 应用端设置：
EXEC sp_set_session_context @key = N'tenant_id', @value = 123 - 安全引用方式：
WHERE tenant_id = ISNULL(CAST(SESSION_CONTEXT(N'tenant_id') AS INT), -1) - 千万别写：
WHERE tenant_id = CAST(SESSION_CONTEXT(N'tenant_id') AS INT)——未设上下文时直接转换失败 - 连接复用时必须重置：
sp_set_session_context不自动清空，旧值可能污染后续请求
外层查询才是动态过滤的实际发生地
无论你用 ITVF、CTE 还是普通视图，“动态”永远只发生在最外层 SELECT 的作用域里。参数不会穿透进子对象内部，子查询也看不到父查询的变量。
- 正确：
SELECT * FROM dbo.fn_orders_by_status('shipped') WHERE created_at > GETDATE() - 1 - 错误：
SELECT * FROM (SELECT * FROM orders WHERE status = 'shipped' AND created_at > GETDATE() - 1) t—— 这不是参数化，只是普通子查询 - CTE 也不行：
WITH filtered AS (SELECT * FROM orders WHERE status = @status)中的@status仍会报错，CTE 不扩展作用域
最容易被忽略的一点：所有“参数化视图”的替代方案，本质都是把过滤逻辑从定义层移到调用层。真正的灵活性不在视图或函数里，而在你写那条 SELECT 时是否留了参数占位、是否做了空值兜底、是否校验了传入的标识符（如表名、排序字段）是否合法。别指望数据库替你做业务规则判断。
