视图不支持参数，硬传会报错；正确做法是用内联表值函数（ITVF）替代，它支持参数且性能接近视图，SQL Server 中可 JOIN、WHERE 下推，PostgreSQL 需 LATERAL，MySQL 可用 CTE 或命名视图折中。
视图本身不能接收参数，硬传会报错
SQL 视图是静态定义的查询结果集，CREATE VIEW 里不支持 WHERE 后跟变量或参数。你如果在视图定义里写 WHERE status = @p_status，执行就会直接报错：Must declare the scalar variable "@p_status"。这不是权限或语法版本问题，而是 SQL 标准决定的——视图编译时就要确定结构，没法“运行时填空”。
常见错误现象：把存储过程里的参数直接塞进视图定义；或者试图用 EXEC('SELECT * FROM myview WHERE col =' + @val) 去“调用视图”，结果发现根本没过滤，因为字符串拼接没生效到视图内部。
- 正确做法是：视图只做基础字段裁剪和关联，过滤逻辑交给上层（比如存储过程、应用代码）
- 如果必须“动态视图”，优先考虑内联表值函数（
ITVF），它支持参数且性能接近视图 - SQL Server 2016+ 可用
APPLY+ 表值函数组合，避免游标或临时表
用内联表值函数替代视图实现参数化
CREATE FUNCTION dbo.fn_orders_by_status(@status VARCHAR(20)) 是最贴近“带参视图”的方案。它返回表，可直接 SELECT * FROM dbo.fn_orders_by_status('shipped')，还能被优化器展开，执行计划干净。
和多语句表值函数（MTVF）不同，内联函数（ITVF）本质就是参数化视图，没有临时表开销，也不阻断统计信息传递。而 MTVF 返回的是不可推演的“黑盒”，JOIN 时容易走嵌套循环，数据量大了就慢。
- 函数体必须是单个
SELECT，不能有BEGIN……END或变量赋值 - 不要在函数里调用
GETDATE()这类非确定性函数，否则无法被索引视图引用 - SQL Server 中，
ITVF可以像视图一样参与JOIN、WHERE下推，但 PostgreSQL 需用LATERAL才能等效
存储过程中调用视图的典型陷阱
很多人以为“在存储过程里 SELECT * FROM myview WHERE …… 就算动态过滤”，这没错，但容易忽略两点：一是视图底层可能已含 WHERE，叠加后逻辑错乱；二是没加 OPTION (RECOMPILE) 导致参数嗅探失效。
比如视图定义里已有 WHERE is_active = 1，你在存储过程中再加 AND status = @p，看起来没问题，但如果 @p 值分布极不均匀（95% 是 ‘pending’），而首次编译用了 ‘completed’ 的执行计划，后续全走低效索引扫描。
- 检查视图定义是否含隐式过滤，避免条件重复或冲突
- 对关键参数化查询，显式加
OPTION (RECOMPILE)，尤其当参数取值范围大、基数差异高时 - 避免在存储过程中用
EXEC sp_executesql拼接视图名——既难审计，又绕过权限检查
PostgreSQL 和 MySQL 的替代路径
PostgreSQL 没有真正意义上的“参数化视图”，但可用 CREATE VIEW + WITH 子句临时绑定变量（仅限当前查询），或更稳妥地用 PREPARE + EXECUTE 配合视图。MySQL 8.0+ 支持公用表表达式（CTE）内联参数，但 CTE 不能复用，每次都要重写。
一个实用折中：在应用层生成视图别名，如 SELECT * FROM orders_vw_pending、orders_vw_shipped，背后共用同一张物理表，靠命名区分过滤逻辑。运维简单，兼容所有版本，缺点是 DDL 多一份。
- PostgreSQL 推荐用
SECURITY DEFINER函数封装视图逻辑，避免权限泄露 - MySQL 中，若用
VIEW+ 应用层拼WHERE，注意 SQL 注入风险，必须参数化处理 - 三者都回避不了一个事实：真正的“动态视图”本质是查询模板，不是对象——别指望靠 DDL 解决运行时问题
参数化过滤的边界其实很清晰：数据库层只管结构稳定性和执行效率，动态逻辑得由调用方承担。越想让视图“聪明”，越容易掉进重编译、权限、跨版本兼容的坑里。
