视图不存数据，每次查询实时重跑 SQL；临时表存物理数据但仅限当前会话；物化视图兼顾二者优势但需数据库支持。
视图不存数据，每次查都是实时重跑 SQL
视图本质是“命名的 SELECT 语句”，数据库只保存定义，不存一行结果。你执行 SELECT * FROM v_user_active，DBMS 会把视图定义展开，再和你的 WHERE、JOIN 合并重写，最终全量扫描基表——哪怕你只是想查 1 条记录。
- 适合场景：权限隔离（如隐藏
salary字段）、封装多表 JOIN 逻辑、统一报表口径 - 性能风险：嵌套视图（VIEW on VIEW）会让执行计划变复杂，优化器可能放弃索引；
ORDER BY在视图定义里会被忽略（除非配合TOP或LIMIT） - 常见错误：
UPDATE v_user_active SET name='x' WHERE id=1大概率失败——多表视图默认不可更新，单表视图也受限于字段是否可计算、是否有 NOT NULL 约束等
临时表真存数据，但只活在当前会话里
临时表是物理存在的表（哪怕引擎是MEMORY），数据实实在在写进tempdb（SQL Server）或会话私有空间（MySQL）。它不像视图那样每次重算，而是“算一次，用多次”。
- 适合场景：存储过程里分步关联 7 张表（先 A +B→#tmp1，再 #tmp1+C→#tmp2）；导出前按条件过滤并预聚合大表；避免同一 SQL 反复扫描 TB 级日志表
- 关键限制：
CREATE TEMPORARY TABLE在 MySQL 中不能被子查询引用两次（SELECT * FROM #tmp, #tmp AS t2报错Can't reopen table）；SQL Server 局部临时表名必须以#开头，全局用## - 容易踩坑：忘记加索引——
INSERT INTO #sales SELECT * FROM orders WHERE dt>='2025-01-01'后直接JOIN，没建INDEX IX_order_id ON #sales(order_id)，后续查询慢十倍
什么时候该用物化视图（索引视图）而不是临时表？
如果你需要“视图的接口 + 临时表的性能”，又要求跨会话复用，且数据库支持（SQL Server/Oracle/PostgreSQL 15+），优先考虑物化视图（Indexed View）。它把视图结果固化存储，并自动维护一致性。
- 优势：查询时直接走聚集索引，不触发基表扫描；支持被查询优化器自动匹配（即使 SQL 里没写视图名）
- 硬性条件：SQL Server 要求视图必须有唯一聚集索引，且
SCHEMABINDING绑定；基表不能有GETDATE()这类非确定函数；SELECT列表不能含*或未明确别名的列 - 替代方案：若数据库不支持物化视图（如 MySQL 8.0 原生不支持），临时表 + 显式索引是更可控的选择，虽然要自己管理生命周期
临时表和视图混用时最常忽略的一点
视图定义里不能引用临时表——这是硬性语法限制（CREATE VIEW v_tmp AS SELECT * FROM #t 直接报错）。反过来，临时表可以 SELECT 视图，但要注意：如果视图底层涉及大表扫描，INSERT INTO #tmp SELECT * FROM v_complex 这一步就已耗尽资源。
- 真实陷阱：在存储过程中先建
#tmp，再建v_summary试图封装 #tmp 逻辑——不行，视图无法感知会话级对象 - 可行解法：用表变量（
DECLARE @t TABLE(……)）替代局部临时表，它可在同一批处理中被多次引用；或改用 CTE（WITH cte AS (……)）做逻辑拆分，虽不持久但无命名冲突 - 最后提醒：临时表名重复不报错（不同会话可同时有
#log），但同一个会话里重复CREATE TEMPORARY TABLE #log会失败，记得加DROP TEMPORARY TABLE IF EXISTS #log
