临时表建完不加索引性能更差，因默认无索引导致JOIN或GROUP BY时全表扫描；应在INSERT后立即在关联/分组字段建索引，并将高选择性WHERE条件下推至构建阶段。
临时表建完不加索引，性能反而更差
SQL Server、PostgreSQL 和 MySQL 8.0+ 都支持显式创建临时表（CREATE TEMP TABLE 或 CREATE GLOBAL TEMPORARY TABLE），但很多人只关注“把中间结果存下来”，忽略索引。临时表默认无索引，后续对它做 JOIN 或 GROUP BY 时，优化器大概率走全表扫描——尤其当临时表有几十万行以上，比直接连查原表还慢。
实操建议：
- 在
INSERT INTO temp_table SELECT ...完成后，立刻用CREATE INDEX在关联字段和分组字段上建索引（如user_id、order_date） - SQL Server 中，
CREATE TABLE #t (...)后可直接CREATE CLUSTERED INDEX IX_t_uid ON #t(user_id)；PostgreSQL 要等SELECT INTO TEMP或CREATE TEMP TABLE AS执行完再建 - MySQL 临时表（
CREATE TEMPORARY TABLE）支持INDEX，但 MEMORY 引擎不支持 BLOB/TEXT 类型索引，别在varchar(2000)字段上盲目加索引
WHERE 条件提前下推到临时表构建阶段
常见错误是：先用宽泛条件查出大结果集进临时表，再在后续 SQL 里反复过滤。这浪费 I/O 和内存，也拖慢索引生效效果。
正确做法是把高选择性过滤条件（如 status = 'paid'、created_at >= '2024-01-01'）直接写进临时表的 SELECT 子句中：
CREATE TEMP TABLE tmp_orders AS SELECT order_id, user_id, amount, created_at FROM orders WHERE status = 'paid' AND created_at >= '2024-01-01'; -- 这步就筛掉 90% 数据
这样临时表体积小，索引更紧凑，JOIN 时驱动表顺序也更容易被优化器选对。
避免在临时表上反复 INSERT + TRUNCATE 做“伪迭代”
有些逻辑需要按时间窗口或用户分组循环处理，开发者会写 TRUNCATE #tmp; INSERT INTO #tmp SELECT ... WHERE group_id = @i 循环 N 次。这不仅引发大量日志写入，还让统计信息失效，导致后续执行计划不准。
更稳的方式：
- 一次性把所有需处理的数据载入临时表，并加一个分组标识字段（如
batch_id int） - 用窗口函数或
ROW_NUMBER() OVER (PARTITION BY ...)划分批次，在单次查询中完成聚合 - 若真需分批，改用表变量（SQL Server）或 CTE +
LIMIT/OFFSET（PostgreSQL/MySQL），减少物理写
不同数据库对临时表索引的支持差异要盯紧
不是所有临时表都能自由建索引。MySQL 5.7 的 MEMORY 临时表不支持非唯一索引；PostgreSQL 的 TEMP TABLE 支持全部索引类型，但统计信息默认不自动收集（得手动 ANALYZE tmp_table）；SQL Server 的本地临时表（#t）能建聚集/非聚集索引，但全局临时表（##t）的索引会被多个会话共享，存在并发 DDL 风险。
关键点：
- 建完索引后，务必检查执行计划是否真用了它（看
Index Seek或Bitmap Heap Scan，而非Seq Scan） - PostgreSQL 中，临时表默认不继承父表约束和索引，别指望
CREATE TEMP TABLE AS SELECT * FROM real_table自带索引 - SQL Server 若用
SELECT INTO #t创建临时表，无法在同一批处理中建索引（语法报错），得拆成两步
临时表不是银弹，索引也不是越多越好。字段重复率低、查询高频过滤、且数据量明显大于内存缓冲区时，才值得加索引——否则维护开销可能盖过收益。
