临时表不一定比表变量慢，关键看数据量和使用场景：≤100行且单次只读用表变量更优；超1000行或需多次JOIN/过滤时必须用带索引的临时表，且索引须建于INSERT前，否则执行计划易误判导致性能断崖下跌。
SQL Server 里临时表比表变量还慢？先看数据量和复用次数
临时表（#temp_table）不是万能解药，它在 SQL Server 中每次执行都触发物理创建、统计信息生成和销毁。当数据量 ≤ 100 行、只读且仅用一次时，@table_variable 更轻量；一旦行数超 1000 或需多次 JOIN/过滤，表变量反而让优化器误估为 1 行，强制走嵌套循环，性能断崖式下跌。
实操建议：
- 数据量 @result TABLE，省日志、免统计开销
- 数据量 > 1000 行 或后续要
JOIN大表 → 必须改用#result，否则执行计划大概率错 - 同一中间结果要在多个分支逻辑中复用（比如先算汇总、再按汇总过滤、再关联明细）→ 只能用
#temp_table，表变量作用域太窄，跨 BEGIN...END 就失效 - 存储过程嵌套调用时，
@t值可能被覆盖，而#t在会话级隔离更稳
建索引必须在 INSERT 之前，否则白干
很多人写了 CREATE INDEX IX_id ON #t(id) 却没生效，是因为在 INSERT INTO #t SELECT ... 之后才建索引。SQL Server 会因此强制重编译后续所有语句批次，首次执行反而更慢。
实操建议：
- 索引必须在
INSERT前创建：CREATE TABLE #t (id INT, val DECIMAL(18,2)); CREATE INDEX IX_id ON #t(id); INSERT INTO #t SELECT ... - 避免为每个 WHERE 字段单独建单列索引，优先组合索引，例如
WHERE status = ? AND created_at > ?→ 建(status, created_at) - 别对
IDENTITY列再建聚集索引——默认就是聚集的，重复建等于浪费资源 - 如果只查一次且条件固定（如
WHERE id IN (1,2,3)），考虑直接用WHERE id IN (SELECT ...)替代建索引的临时表
MySQL 里 SELECT INTO 多次赋值会锁表，别在循环里用
SELECT col INTO @var FROM t WHERE id = ? 看似简洁，但在循环内反复执行时，每条都会触发独立查询 + 行级锁，高并发下极易卡住。更麻烦的是，@var 是会话级变量，嵌套调用时值可能被意外覆盖。
实操建议：
- 批量提取改用临时表：
CREATE TEMPORARY TABLE tmp_cache AS SELECT id, calc_col FROM t WHERE ... - 需要单值时，优先用聚合函数：
SELECT MAX(calc_col) FROM t WHERE ...，让优化器走索引覆盖 - 绝对避免在游标循环里用
INTO赋值后再计算——把逻辑全下推到SELECT子句，例如：SELECT id, price * tax_rate AS final_price FROM t - PostgreSQL 同理，
SELECT ... INTO在 PL/pgSQL 中也应慎用，优先用CREATE TEMP TABLE AS
真正卡顿的不是临时表本身，而是执行计划反复失效
临时表泛滥最隐蔽的代价，是 SQL Server 无法准确预估其行数，导致后续 JOIN 或 WHERE 的执行计划频繁错判。你看到的“慢”，往往不是 I/O 慢，而是优化器选了 Nested Loop 而不是 Hash Join，或者该走索引却走了全表扫描。
检查信号：
- 执行计划里连续出现多个
Table Insert+Clustered Index Scan→ 中间表滥用 - 同一存储过程在不同参数下耗时差异极大 → 统计信息未更新，或基数估算严重偏离
- 高频调用的存储过程
sys.dm_exec_query_stats.total_logical_writes持续偏高 → 临时表 I/O 压力已成瓶颈
临时表命名带 SUBSTRING(NEWID(),1,8) 可防冲突，但解决不了执行计划不准的问题——关键还是控制中间结果规模、及时更新统计信息、以及把 GROUP BY / JOIN 条件尽量下推到最外层。
