视图不存数据，每次查询实时重跑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
