不能。sql视图在定义阶段即禁止引用临时表（如#temp或@table_var），因视图需持久化跨会话复用，而临时表仅限当前会话、结构不稳定，数据库在语法解析时就硬性拦截，sql server报msg 4508，postgresql和mysql同理限制。
视图定义阶段就拒绝临时表引用
SQL 视图无法在 CREATE VIEW 语句里直接创建或引用临时表（如 #temp 或 @table_var），不是语法写错，也不是权限问题——是数据库引擎在解析视图定义时就硬性拦截。SQL Server 报 Msg 4508, Level 16, State 1: Views or functions are not allowed to reference temporary tables.，PostgreSQL 和 MySQL 同样明确禁止。根本原因在于：视图的元数据必须持久化、可跨会话复用，而临时表只在当前会话生命周期内存在，结构可能每次都不一致，引擎无法保证依赖关系稳定。
CREATE TEMPORARY TABLE 在视图体里根本不会执行
你不能在视图的 SELECT 体中写 CREATE TEMPORARY TABLE，因为视图不是可执行代码块，它只是封装好的查询逻辑定义。数据库不会在视图创建时运行 DDL，也不会在每次查询视图时动态建临时表——这既违背视图语义，也破坏事务一致性。哪怕你把 CREATE TEMPORARY TABLE 包进存储过程再从视图调用，SQL Server 和 PostgreSQL 仍会直接报错；MySQL 则在解析阶段就拒绝含 DDL 的视图定义。
为什么“先建临时表再创视图”也不行？
即使你在会话里手动执行了 CREATE TABLE #t AS SELECT ...，紧接着跑 CREATE VIEW v AS SELECT * FROM #t，依然失败。原因很直接：#t 是会话私有对象，视图定义需要被其他会话访问，而别的会话根本没有这个 #t。系统无法将一个非持久、不可见、无全局元数据的对象绑定到视图依赖链中。DBA 查 sys.dm_exec_describe_first_result_set 或 INFORMATION_SCHEMA.VIEWS 时，根本无法推断出这种视图的列结构和类型。
真正能落地的替代路径只有三条
别试图绕过限制，得按数据生命周期重新组织：
- 如果中间结果要复用多次 → 改用带命名规范的物理表（如
stg_orders_daily），配合定时清理或分区策略 - 如果逻辑需参数化（比如按日期/状态过滤）→ 封装成内联表值函数（
ITVF），例如CREATE FUNCTION dbo.fn_orders_by_status(@s NVARCHAR(20)) RETURNS TABLE...，再在视图里SELECT * FROM dbo.fn_orders_by_status('shipped') - 如果只是为简化单条复杂查询 → 直接把原临时表的
SELECT拆进视图定义，用 CTE 或派生表替代，避免额外对象层级
最常被忽略的一点：临时表和视图解决的是不同维度的问题——前者管“执行时暂存”，后者管“逻辑层抽象”。混用它们，本质上是把运行期行为塞进了编译期契约里。
