sql中不存在临时视图，因视图是持久化查询定义而“临时”要求会话级生命周期，二者本质冲突；主流数据库均不支持create temp view语法，需依场景选用view（封装逻辑）或temporary table（物化中间结果）。
临时视图在SQL中并不存在——所有主流数据库（PostgreSQL、MySQL 8.0+、Hive、Spark SQL）都不支持“临时视图”语法。你真正需要的，是明确区分 VIEW 和 TEMPORARY TABLE 的使用边界，避免把临时表误叫成“临时视图”。
为什么没有临时视图？这不只是命名问题
视图本质是保存的查询文本，不是对象实例；而“临时”意味着生命周期绑定会话或事务。二者逻辑冲突：CREATE TEMP VIEW 在 PostgreSQL 报错 ERROR: syntax error at or near "TEMP"，MySQL 直接不识别该语法，Hive/Spark SQL 也不支持。试图用视图模拟临时行为（比如加 WHERE dt = '${bizdate}'）只是参数化，不是临时性。
- 视图定义一旦创建，就全局可见（除非权限限制），无法按会话隔离
- 所谓“临时效果”，实际靠调度变量（如
${bdp.system.bizdate}）或调用方传参实现，不是视图自身能力 - 真要会话级隔离 + 可写 + 可索引 + 可反复 JOIN，只能选
TEMPORARY TABLE
当清洗逻辑复杂到必须拆步时，该用临时表而不是“假装有临时视图”
典型场景：原始日志表含千万级乱序事件，需先去重、再按用户+会话窗口聚合、最后关联维表补城市信息。这类操作无法塞进视图——窗口函数不能被视图 WHERE 过滤，ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY ts) 的结果无法在视图外直接筛出“每个用户的首条事件”。
- 第一步建临时表做轻量清洗：
CREATE TEMPORARY TABLE clean_log AS SELECT user_id, TRIM(LOWER(device_id)) AS device_key, CAST(event_time AS TIMESTAMP) AS ts FROM raw_log WHERE event_time >= CURRENT_DATE - INTERVAL '3 days' - 第二步加索引加速后续关联：
CREATE INDEX ON clean_log (user_id, ts)（PostgreSQL 需ANALYZE clean_log后生效） - 第三步用该临时表跑窗口逻辑：
SELECT user_id, FIRST_VALUE(page) OVER (PARTITION BY session_id ORDER BY ts) AS first_page FROM clean_log
哪些清洗动作看似能放视图，实则一上线就拖垮ETL调度
错误认知：“我把 COALESCE() 和 REGEXP_REPLACE() 写进视图，就算做了清洗”。问题在于，当底层表达亿级且无分区裁剪时，这些函数会全表扫描执行——而临时表可配合 WHERE 提前过滤，再对小数据集处理。
- 视图里写
WHERE status IN ('active', 'trial')：下游调用方若只想要active，仍得全扫原表再过滤，无法利用索引 - 视图里
JOIN dim_city ON raw_log.city_code = dim_city.code：每次查视图都触发跨表关联，无法缓存中间结果 - 用视图封装
LAG()或COUNT(*) OVER (PARTITION BY ...)：PostgreSQL 会强制 materialize 分区，MySQL 可能生成 Derived 表，EXPLAIN 显示MATERIALIZE步骤即告警
临时表不是万能解药，但比硬塞视图靠谱得多
关键区别不在“有没有”，而在“要不要固化状态”。ETL 清洗的本质是状态转换：空值标记为 'unknown' 是单行映射，可放视图；但“剔除重复设备 ID 的首次登录”必须固化去重结果，否则每次下游调用都重算，成本指数上升。
- 临时表适合：需要索引、需多次 JOIN、含窗口/聚合/UPDATE、结果集比原表小一个数量级以上
- 视图适合：字段重命名、类型强制转换（
CAST）、单行字符串清洗（TRIM(LOWER())）、基础空值兜底（COALESCE(col, 'unknown')） - 真正容易被忽略的点：临时表在 PostgreSQL 中默认事务级生命周期，若 ETL 脚本分多条语句执行且未显式
BEGIN，表会在第一条后就销毁；MySQL 临时表会话级存在，但跨连接（如 Airflow 多 worker）不共享——别指望它自动传递
