该用 CREATE VIEW 而不是 CREATE TEMPORARY TABLE 时：需封装复用查询逻辑、隐藏底层结构、依赖权限控制或容忍实时执行开销；临时表则适用于需物化中间结果、多次读写、建索引或状态标记的 ETL 场景。
视图不存数据，临时表存数据；用完即删的中间结果选临时表，反复查同一逻辑口径选视图。
什么时候该用 CREATE VIEW 而不是 CREATE TEMPORARY TABLE
当你需要封装查询逻辑、复用且不希望暴露底层表结构时，视图是更轻量的选择。它只是保存 SQL 语句，每次 SELECT 都实时执行原始查询。
- 权限控制方便：给用户授
SELECT权限到视图，就能限制其看到的字段和行 - 底层表结构变更（如加列）不影响视图调用，只要
SELECT语句仍合法 - 不能写入：
INSERT/UPDATE到视图通常受限（除非是简单单表、无计算列、无聚合） - 性能注意：复杂视图嵌套多层时，优化器可能无法下推谓词，导致全量扫描
为什么 CREATE TEMPORARY TABLE 在 ETL 中更常用
临时表把中间结果物化进内存或磁盘（取决于引擎和大小），后续多个步骤可反复读取、加索引、分批处理——这是视图做不到的。
- 支持
INSERT/UPDATE/DELETE，适合清洗过程中的状态标记（比如加is_valid标志位） - 可建索引：
CREATE INDEX idx_on_temp ON temp_table(col)能显著加速后续JOIN或WHERE - 生命周期明确：会话结束自动销毁，不用手动
DROP（但显式DROP TEMPORARY TABLE更稳妥） - 注意引擎差异：MySQL 的
TEMPORARY表只对当前连接可见；PostgreSQL 用CREATE TEMP TABLE，行为类似；SQL Server 是#temp表，作用域为 session
SELECT ... INTO #temp 和 CREATE TABLE + INSERT 哪个更快
在 SQL Server 中，SELECT ... INTO #temp 是隐式建表+插入，通常比显式两步快，因为省去元数据锁竞争和日志开销。但它不能预定义索引、约束或数据类型精度。
- 若需精确控制列类型（比如避免
varchar(255)自动截断为varchar(8000)），必须用CREATE TABLE #temp (...) ; INSERT INTO #temp SELECT ... - MySQL 不支持
SELECT ... INTO TEMPORARY TABLE，只能用CREATE TEMPORARY TABLE ... AS SELECT，效果等同于SELECT INTO - PostgreSQL 不支持
INTO创建临时表，必须用CREATE TEMP TABLE AS SELECT
容易被忽略的兼容性陷阱
不同数据库对“临时”的实现差异极大，跨平台迁移脚本时极易出错。
- MySQL 的
TEMPORARY表不能被子查询引用两次（报错Table 'xxx' doesn't exist），需改用 CTE 或普通表 - PostgreSQL 的临时表默认在事务结束后不删除，而是持续到会话结束；想提前清理得用
ON COMMIT DROP - SQL Server 的
#temp表在存储过程中创建后，无法被调用它的上层批处理直接访问（作用域隔离） - 所有数据库中，视图定义里都不能含变量或参数——要动态过滤，得靠应用层拼 SQL 或用函数封装
真正难的不是语法选择，而是判断“这个中间结果会不会被多次读取”“是否需要修改状态”“下游是否依赖确定的数据类型”。一旦模糊，就先建临时表，再看能否抽象成视图——而不是反过来。视图一旦被业务代码大量引用，改起来比临时表麻烦十倍。
