临时视图本身不加速，仅当同一中间结果被多次引用且原始数据稳定时才可能提升效率；真正加速需依赖避免重复扫描、优化器固化形态或配合物化（如cache table、临时表）。
临时视图在SQL批处理中真能加速吗？
多数情况下不能——临时视图（比如 CREATE TEMP VIEW 或 WITH 子句定义的 CTE）本身不缓存数据，只是逻辑重写入口。真正起加速作用的是：① 避免重复扫描同一张大表；② 让优化器提前固化中间结果形态；③ 配合物化（如 PostgreSQL 的 MATERIALIZED 临时表或 Spark SQL 的 CACHE TABLE）。盲目建临时视图反而可能拖慢，尤其当底层表无索引、视图嵌套过深时。
哪些场景下临时视图确实提升批处理效率？
适用前提是「同一中间结果被多次引用」且「原始数据不易变更」。典型例子：从日志表提取昨日活跃用户，后续要分别统计登录次数、订单数、设备分布。
- 用
WITH active_users AS (SELECT DISTINCT user_id FROM logs WHERE dt = '2024-06-15')定义一次，后面多处JOIN引用，比重复写子查询更易读，也便于优化器复用执行计划 - 在支持物化的引擎里（如 Spark SQL），可紧接着执行
CACHE TABLE active_users，把结果固化到内存/磁盘，后续操作直接读缓存 - PostgreSQL 中若需强物化，应改用
CREATE TEMP TABLE active_users AS SELECT ...，而非CREATE TEMP VIEW—— 视图每次调用都重算，临时表只算一次
MySQL / SQL Server 用户注意：你们没有标准临时视图
MySQL 8.0+ 支持 CTE（WITH），但不支持物化；SQL Server 的 CTE 同样是逻辑视图，且有递归深度限制。这两个系统若想真正加速，得换策略：
- MySQL：用
CREATE TEMPORARY TABLE tmp_active_users AS SELECT ...，显式建临时表并加索引（如ALTER TABLE tmp_active_users ADD INDEX (user_id)） - SQL Server：用
SELECT ... INTO #active_users创建本地临时表，它自动走 tempdb，比反复查原表快得多 - 两者都避免在 CTE 里写
ORDER BY或窗口函数后又多次引用——这会强制多次执行排序或计算
容易被忽略的性能陷阱
临时视图不是银弹，下面这些操作会让它变成负优化：
- 在
WITH子句里引用未加索引的大表，且外层查询又没过滤条件——等于每次调用都全表扫一遍 - 嵌套超过 3 层 CTE（如 A → B → C → 主查询），某些数据库（如旧版 Presto）会退化成多次独立执行
- 视图里用了
NOW()、RAND()等非确定性函数，导致无法缓存，还可能让结果不一致 - 在事务中创建临时视图但没及时
DROP（PostgreSQL），可能阻塞统计信息收集或锁住系统表
真正省时间的地方，往往不在“怎么定义视图”，而在“是否该用临时表替代”以及“原始数据上有没有合适的分区键和索引”。
