临时表能加速大规模INSERT，但需作为可控中间层使用：必须建索引、下推过滤、精准驱动，且目标表关联字段也需索引；否则性能反不如直接INSERT INTO SELECT。
临时表能加速大规模 INSERT，但前提是它被当作“可控中间层”来用，而不是简单把 SELECT 结果塞进去就完事——漏掉索引、引擎选错或没下推过滤条件，反而比直接 INSERT INTO SELECT 还慢。
CREATE TEMPORARY TABLE 后必须立刻建索引
临时表默认无主键、无索引，后续 JOIN 或 INSERT 时优化器大概率走全表扫描。尤其当临时表有 10 万+ 行，没索引的代价远超写入开销。
- MySQL：建表后立刻执行
ALTER TABLE temp_batch ADD PRIMARY KEY (id)或CREATE INDEX idx_ref ON temp_batch (ref_id) - SQL Server：
CREATE CLUSTERED INDEX IX_temp_ref ON #temp_batch(ref_id)，聚簇索引对后续 JOIN 驱动更友好 - PostgreSQL：
CREATE INDEX idx_ref ON temp_batch (ref_id)，建完立即ANALYZE temp_batch - 别用
CREATE TEMPORARY TABLE AS SELECT一步到位——它不支持PRIMARY KEY语法糖，字段类型也可能隐式变成VARBINARY，导致后续 JOIN 失败
INSERT INTO SELECT 前先用临时表做精准驱动
直接 INSERT INTO target SELECT ... FROM big_table JOIN dim_table 容易触发全表扫描或嵌套循环，尤其当 big_table 超百万行。用临时表把驱动侧收窄，才是提速关键。
- 先构建小范围驱动集：
CREATE TEMPORARY TABLE temp_batch AS SELECT id FROM orders WHERE status = 'shipped' AND created_at >= '2026-09-01'（高选择性条件必须下推） - 再用它驱动关联：
INSERT INTO fact_sales (...) SELECT o.id, o.amount, d.region FROM temp_batch o JOIN dim_region d ON o.region_id = d.id - 确保
EXPLAIN显示驱动表是temp_batch，且type是ref或range，不是ALL - 如果目标表
fact_sales的region_id没索引，JOIN 仍会扫全表——临时表快，不代表整体快
分批处理时别反复 TRUNCATE + INSERT
用循环 TRUNCATE #tmp; INSERT INTO #tmp SELECT ... WHERE batch_id = @i 看似可控，实则埋雷：统计信息失效、日志暴涨、执行计划漂移。
- 一次性载入全部待处理数据，并加批次标识：
SELECT id, ..., FLOOR((ROW_NUMBER() OVER (ORDER BY id) - 1) / 10000) AS batch_no INTO #tmp_all FROM source WHERE ... - 每次只取一个 batch：
INSERT INTO target SELECT ... FROM #tmp_all t JOIN dim ON t.ref = dim.id WHERE t.batch_no = 0 - 单次处理 5k–50k 行较稳；若关联字段有联合索引（如
(ref_id, status)），可放大到 10 万；否则压到 2 万以内 - 别依赖
innodb_stats_auto_update=ON——它对临时表基本不生效，INSERT 后必须手动ANALYZE TABLE #tmp_all
ENGINE=MEMORY 不是默认最优解
很多人默认选 ENGINE=MEMORY 图快，但它有硬限制：不支持 TEXT/BLOB，超出 max_heap_table_size 会自动转磁盘表（MyISAM 或 InnoDB），多一次转换开销，反而更慢。
- 数据量 >10MB 或含长文本字段，显式指定
ENGINE=InnoDB：CREATE TEMPORARY TABLE temp_batch (...) ENGINE=InnoDB - SQL Server 本地临时表（
#tmp）默认走tempdb，无需指定引擎，但要注意tempdb文件是否预分配充足 - PostgreSQL 的
TEMP TABLE默认在pg_temp_*schema，数据落共享内存或磁盘由系统决定，无法强制内存 - 云数据库（如阿里云 RDS）部分版本禁用
ANALYZE，此时改用OPTIMIZE TABLE temp_batch（仅 InnoDB 有效）
临时表本身不加速，加速的是你对数据边界、索引和执行路径的控制力。最容易被忽略的，其实是“插入后立刻 ANALYZE”和“关联字段在目标表上也要有索引”这两点——它们不写进代码，但缺一不可。
