临时表本身不危险，危险的是没索引、没清理、没控制生命周期的“裸用”；其默认无索引导致JOIN/ORDER BY全表扫描，易引发tempdb溢出，且生命周期绑定事务易致空间无法及时释放。
临时表本身不危险，危险的是没索引、没清理、没控制生命周期的“裸用”。
临时表默认无索引，JOIN/ORDER BY全靠扫描
很多人写 SELECT * INTO #tmp FROM ... 后直接 JOIN #tmp 或 ORDER BY #tmp.col，却不知道 SQL Server 生成的 #tmp 默认只有堆结构，没有任何索引。后续所有关联、过滤、排序都只能走全表扫描，触发大量 Sort 和 Hash Match 溢出——执行计划里一出现 SpillLevel="1" 或警告 "Operator used tempdb to spill data"，基本就是它在作祟。
- 显式建表代替
SELECT INTO：先CREATE TABLE #tmp (id INT, status VARCHAR(20))，再INSERT - 建聚集索引：如
CREATE CLUSTERED INDEX IX_#tmp_id ON #tmp (id)，尤其当id是后续 JOIN 主键时 - 非聚集索引要覆盖常用条件字段：例如
WHERE status = 'done'就得有CREATE NONCLUSTERED INDEX IX_#tmp_status ON #tmp (status)
事务未及时提交，tempdb空间无法复用
临时表生命周期绑定会话+事务。如果在长事务里反复 INSERT INTO #tmp，又不 COMMIT，那这些页就一直被标记为“已分配”，哪怕你 DROP TABLE #tmp，SQL Server 也不会立刻释放底层空间——因为事务还没结束，版本链和分配位图都还挂着。此时查 sys.dm_db_session_space_usage 会发现 user_objects_alloc_page_count 持续上涨，但 user_objects_dealloc_page_count 几乎不动。
一款AI音频处理工具，主要用于MiniMax统一媒体生成技能，用于TokenPlan工作流。当用户要求生成音频、语音、TTS、旁白、图片、插图、姿势等媒体内容时使用，适合需要提升相关任务效率的用户。
- 避免在单个事务中塞入多批次大插入：拆成小事务，每批后
COMMIT - 不用
TRUNCATE TABLE #tmp代替DROP TABLE #tmp来“清空”——它不释放分配页，只是重置标识和行计数 - 确认是否真需要临时表：简单逻辑优先用 CTE 或表变量（
@t），它们开销更低且自动清理
嵌套调用中临时表名冲突或重复创建
存储过程 A 调用 B，B 里建了 #tmp，A 里也建了同名 #tmp，SQL Server 允许（因为作用域隔离），但容易掩盖问题：比如 B 执行完后 #tmp 自动销毁，A 继续用自己那个，结果数据错乱；更隐蔽的是，某些 ORM 或连接池场景下，会话被复用，前一次残留的 #tmp 可能干扰后一次执行，导致隐性膨胀。
- 给临时表加唯一后缀：如
#tmp_orders_20260826或用NEWID()截取部分字符 - 显式
DROP TABLE #tmp在使用结束后，别依赖自动销毁 - 避免跨层级共享临时表：若需传递数据，改用表值参数（TVP）或输出参数
最常被忽略的一点：tempdb 空间不是“用完才爆”，而是“估算错就溢”。哪怕你只插 10 万行，只要优化器误判基数（比如子查询返回 1 行，外层 JOIN 后预计 50 行，实际 500 万行），它分的内存 grant 就不够，立刻 spill 到磁盘——这时候看 sys.dm_exec_query_stats 的 total_spills 字段比看 #tmp 大小更有诊断价值。
