优先用视图；中间结果需反复读且加索引时用临时表；跨会话复用且需缓存时看物化视图支持；调试复杂查询分步验证选临时表。
查同一逻辑多次，但不想重复写SQL？优先用视图
如果你在多个报表、接口或存储过程中反复使用同一套查询逻辑（比如「近7天活跃用户」），且底层数据实时性要求高，视图是最轻量的选择。它不存数据，只存SELECT语句，调用时自动展开并和你的WHERE条件合并——只要优化器能下推谓词，性能就接近直接查基表。
- 适合场景：权限控制（如用视图隐藏
salary字段）、统一口径（所有下游都走v_daily_revenue）、封装多表JOIN避免到处复制粘贴 - 容易踩的坑：
CREATE VIEW v_user_detail AS SELECT * FROM users JOIN profiles ...这种写法一旦基表加列，视图定义不变但结果列顺序可能乱；更糟的是嵌套视图（v_a基于v_b，v_b又基于v_c），执行计划会变成套娃子查询，EXPLAIN都难定位瓶颈 - MySQL/PostgreSQL/SQL Server 都支持，但
ORDER BY在视图定义里会被忽略（除非配合LIMIT或TOP）
中间结果要反复读、还要加索引或更新？必须用临时表
当你需要把一次复杂计算的结果固化下来，后续步骤要多次JOIN、WHERE过滤、甚至UPDATE标记状态（比如is_valid = 1），临时表是唯一可行方案。它真写数据到tempdb（SQL Server）、内存或磁盘（MySQL），还能建索引——这是视图和CTE都做不到的。
- 典型动作：
CREATE TEMP TABLE #tmp_order_agg AS SELECT order_id, SUM(amount) FROM orders GROUP BY order_id，然后立刻CREATE INDEX IX_order_id ON #tmp_order_agg(order_id) - 注意兼容性：
MySQL不支持SELECT ... INTO TEMPORARY TABLE，只能用CREATE TEMPORARY TABLE ... AS SELECT；PostgreSQL必须用CREATE TEMP TABLE，不能用INTO；SQL Server支持SELECT ... INTO #temp，但无法预定义列类型精度 - 常见错误：建完
#sales后直接SELECT * FROM #sales JOIN #sales s2 ON ...——MySQL报Table 'sales' doesn't exist，因为临时表不能在同一个查询里引用两次
想兼顾“视图接口”和“临时表性能”，但跨会话复用？看物化视图支持情况
如果业务要求「对外提供视图一样的调用方式，但内部要缓存结果、支持索引、还能被优化器自动匹配」，就得看数据库是否原生支持物化视图。这不是所有系统都有，强行用临时表模拟会失去「自动刷新」和「跨会话共享」能力。
-
SQL Server叫Indexed View，需SCHEMABINDING+ 唯一聚集索引，且SELECT里不能有GETDATE()这类非确定函数 -
PostgreSQL 15+支持MATERIALIZED VIEW，但必须手动REFRESH，不自动同步基表变更 -
MySQL 8.0原生不支持，此时CREATE TEMP TABLE+ 定时任务重建是更可控的替代方案，虽然得自己管生命周期 - 硬限制：
CREATE VIEW里绝对不能引用任何临时表（语法直接报错），反过来临时表也不能作为视图的数据源
调试复杂查询时分步验证逻辑？临时表比嵌套CTE更可靠
写一个涉及5张表关联+窗口函数+过滤的SQL，调试时最怕「改一处，全重跑」。CTE虽可读性好，但每次引用都重新计算（即使同一CTE被用两次），而临时表算一次存下来，后续任意操作都基于快照——这对排查中间结果是否符合预期至关重要。
- 实操建议：先
CREATE TEMP TABLE #step1 AS SELECT ...，SELECT COUNT(*) FROM #step1确认行数；再CREATE TEMP TABLE #step2 AS SELECT ... FROM #step1 JOIN ...，逐层验证 - 别省事：
WITH a AS (...), b AS (SELECT * FROM a), c AS (SELECT * FROM a)看似简洁，但a会被执行两次，大表上可能慢几倍 - 临时表名加业务前缀（如
tmp_user_active_7d）能避免协作时冲突，DROP TABLE IF EXISTS不是必须，但显式清理能让TempDB压力更可预测
真正卡住人的地方，往往不是「该用哪个」，而是没意识到视图的谓词下推失败会导致全表扫描，或者临时表忘了建索引让后续JOIN慢十倍。选型前先问自己：这个结果集要不要被多次不同方式消费？要不要加索引？要不要跨查询复用？答案清晰了，选择就自然浮现。
