不能。SQL视图无法引用临时表，这是主流数据库在编译期强制拒绝的硬性限制，因视图需元数据持久化而临时表仅会话级存在，二者生命周期根本冲突；替代方案应按场景选用永久表、ITVF或CTE等。
SQL视图里用不了 #temp_table，这是数据库引擎的硬性限制
不是语法写错了，也不是权限问题——所有主流关系型数据库（SQL Server、PostgreSQL、MySQL）都明确禁止在 CREATE VIEW 中引用本地临时表（#temp_table）或表变量（@table_var）。根本原因是：视图定义在编译时固化，而临时表只在会话生命周期内存在，且每次执行时可能不存在、结构不一致，无法保证元数据稳定性。
SQL Server 中试图创建含 #temp_table 的视图会直接报错
典型错误信息是：Msg 4508, Level 16, State 1: Views or functions are not allowed to reference temporary tables.。即使你先建好临时表再跑 CREATE VIEW，也会失败——引擎在解析阶段就拒绝了，根本不会等到执行。
- 临时表名在不同会话中不唯一，视图无法绑定到确定对象
- 视图依赖关系无法被系统跟踪，影响查询优化器生成执行计划
- DBA 无法通过
sys.dm_exec_describe_first_result_set等工具可靠推断视图返回结构
替代方案要按使用场景选，别一股脑用 CTE 或 TVF
真正能落地的替代方式取决于你为什么想用临时表：
- 如果是为了中间结果复用（比如多处 JOIN 同一张加工后的表）→ 用
WITHCTE，但注意它只作用于单条语句，不能跨查询复用 - 如果需要跨多个查询共享中间结果 → 改用物理表（带命名规范和清理逻辑），或使用全局临时表（
##global_temp），但要注意并发冲突和残留风险 - 如果逻辑复杂、参数化需求强 → 封装成内联表值函数（
ITVF），例如CREATE FUNCTION dbo.fn_enriched_orders(@status NVARCHAR(20)) RETURNS TABLE AS RETURN (SELECT ...)，然后在视图里SELECT * FROM dbo.fn_enriched_orders('shipped') - 如果只是为简化权限或屏蔽底层表结构 → 直接在视图里写完整逻辑，把原临时表的 SELECT 拆进来，避免抽象层嵌套
PostgreSQL 和 MySQL 的“临时视图”其实不解决本质问题
PostgreSQL 支持 CREATE TEMPORARY VIEW，但它只是当前会话可见的视图，依然不能引用 TEMP TABLE；MySQL 没有临时视图概念，连这个语法都不支持。两者共同点是：视图必须引用持久对象。所谓“替代”，从来不是绕过限制，而是重新组织数据生命周期——把该物化的提前物化，该参数化的做成函数，该拆解的就拆进视图定义里。
最容易被忽略的是：很多人把临时表当“快捷草稿纸”，却忘了视图是生产环境长期存在的对象。一旦开始考虑视图，就得同步考虑它的可维护性、执行一致性，以及 DBA 能否在不登录你个人会话的情况下排查问题。
