应使用内联表值函数（itvf）替代视图实现参数化查询，因其性能最优、支持谓词下推；次选宽视图+外部where；复杂逻辑可用临时表配合存储过程，但无法直接join。
CREATE VIEW 本身不支持动态 SQL，任何试图在视图定义中拼接变量、调用存储过程或使用 EXEC/sp_executesql 的做法都会直接报错：Invalid use of a side-effecting operator 或 'CREATE VIEW' does not allow variables。这不是权限问题，是语法层面禁止。
你真正需要的，不是“把动态 SQL 塞进视图”，而是“让视图行为看起来可参数化”。下面几个方案按推荐度排序，聚焦真实可用性。
用内联表值函数（ITVF）替代视图，实现“带参可 JOIN”的效果
这是 SQL Server 官方推荐、性能最优、且最贴近“动态视图”语义的解法。它不是视图，但调用方式和优化表现几乎一样。
-
CREATE FUNCTION必须是单个SELECT，不能含DECLARE、SET、IF，否则自动降级为多语句表值函数（MSTVF），性能断崖下跌 - 示例：封装按状态过滤的订单逻辑
CREATE FUNCTION dbo.fn_orders_by_status(@status VARCHAR(20)) RETURNS TABLE AS RETURN (SELECT order_id, user_id, created_at FROM orders WHERE status = @status);
- 调用时可直接
JOIN：SELECT u.name, o.* FROM users u INNER JOIN dbo.fn_orders_by_status('shipped') o ON u.id = o.user_id - 执行计划可重用，优化器能下推谓词，不像 MSTVF 那样物化中间结果
视图 + 外部 WHERE：简单场景下的最小改动方案
如果你只是想避免重复写 JOIN 和基础过滤，而参数变化不多（比如固定几个 status 值），建一个宽视图，靠上层查询加 WHERE 过滤即可——它不“动态”，但够用、安全、无兼容性风险。
- 视图定义里保留所有可能被过滤的字段：
CREATE VIEW v_orders_enhanced AS SELECT o.*, u.name AS user_name, ... FROM orders o JOIN users u ON o.user_id = u.id - 应用层或报表工具中直接写：
SELECT * FROM v_orders_enhanced WHERE status = 'pending' AND created_at > DATEADD(day, -7, GETDATE()) - 注意：SQL Server 会对这个
WHERE尝试下推，但若视图含聚合或复杂 CTE，下推可能失效，需看实际执行计划 - 别在视图里写
WHERE 1=0或TOP 0来“占位”——这会让优化器误判基数，反而拖慢后续查询
用临时表/表变量 + 通用存储过程模拟“参数化视图”
当逻辑真要跨会话共享、且涉及多步计算（比如先算用户等级，再关联订单），ITVF 不够用时，可退一步：把参数存入临时结构，再由存储过程读取并返回结果集。
- 客户端先执行：
CREATE TABLE #filter_config (tenant_id INT, status VARCHAR(20), date_from DATE); INSERT INTO #filter_config VALUES (123, 'shipped', '2026-06-01'); - 然后调用统一存储过程：
EXEC dbo.usp_get_filtered_orders;，该过程内部SELECT * FROM orders o JOIN #filter_config f ON ... - 优点：支持任意复杂逻辑，可含事务、错误处理、日志；缺点：无法被
SELECT或JOIN直接引用，只能作为独立结果集消费 - 别用全局临时表（
##xxx）——并发下易冲突；也别在函数里试图读#filter_config，函数不允许访问临时表
真正的难点不在语法，而在于执行计划是否稳定。ITVF 看似简洁，但一旦函数体里用了 OR、ISNULL()、未 SARGable 的表达式（如 WHERE YEAR(created_at) = 2026），优化器就可能放弃参数嗅探，导致不同参数值跑出完全不同的执行路径。上线前必须用不同参数实测执行计划。
