频繁CREATE/DROP临时表拖慢存储过程，因其是隐式提交的DDL操作，每次均强制落盘写入tempdb或ibtmp1，并引发PFS/GAM页争用与元数据锁冲突；应优先用表变量（@table）替代，适用于≤100行的小量中间结果。
为什么频繁 CREATE/DROP 临时表会拖慢存储过程
因为 CREATE TABLE #t 和 DROP TABLE #t 是隐式提交的 DDL 操作，不是“可能”触发 IO，而是每次执行都必须落盘：SQL Server 要写 tempdb 数据文件 + 日志页，MySQL 要同步清理 ibtmp1 文件和 frm 元数据。高并发下，SOS_SCHEDULER_YIELD 等待在 PFS/GAM 页上堆积，Created_tmp_disk_tables 每秒涨几十个，基本就是元数据锁争用导致的性能拐点。
优先改用表变量（@table）的适用场景
当数据量小（通常 DECLARE @t TABLE (id INT, name VARCHAR(50)) 是更轻量的选择。它不走 tempdb 数据文件分配流程，只在内存中构造结构，也不生成统计信息，避免了 DDL 开销。但注意：@t 不支持非聚集索引、CHECK 约束、外键，且在复杂 JOIN 中优化器可能误估行数，导致执行计划退化。
必须用临时表时，如何复用结构而非反复重建
SQL Server 支持本地临时对象缓存，但前提是满足三个条件：在存储过程中创建、未显式建索引、未手动更新统计信息。实际操作中可这样写：
- 把
IF OBJECT_ID('tempdb..#tmp')判断 +DROP全部删掉——让 SQL Server 自己决定是否缓存 - 首次创建后，后续直接
TRUNCATE TABLE #tmp清空数据，而不是DROP+CREATE - 避免在
CREATE TABLE #tmp后立刻加CREATE INDEX，否则缓存失效 - 如果真需要索引，改用
SELECT ... INTO #tmp一次建表带数据，再建索引（此时仍可被缓存）
替代方案：CTE 或子查询能否绕过临时对象
能，但有边界。CTE（WITH cte AS (...)）适合单次引用、逻辑清晰的中间结果；子查询适合嵌套过滤。它们不产生物理对象，自然避开所有 tempdb 争用。但若同一中间结果需被多次 JOIN 或聚合，CTE 会被重复计算，反而比缓存后的 #tmp 更慢。判断标准很简单：看执行计划里对应步骤是否出现多次“Table Spool”或“Compute Scalar”——出现就说明 CTE 被重算，该换临时表。
真正难处理的是嵌套循环内建临时表、或动态 SQL 中拼接表名的场景，这些连缓存机制都覆盖不到，必须重构逻辑。临时对象不是“用完即弃”的语法糖，它是有重量的物理资源——设计阶段就要想清楚生命周期，而不是等监控报警了再查 sys.dm_io_virtual_file_stats。
