窗口函数无需创建临时表，不写入tempdb，执行计划中无Table Insert或Table Spool节点即无tempdb压力；可复用原表索引，避免重复排序与中间表开销。
窗口函数能直接绕过临时表的物理创建、写盘、索引重建和清理全过程，只要执行计划里不出现 Table Insert 或 Table Spool 节点，就基本没 tempdb 压力。
窗口函数不写 tempdb，临时表必须写
SQL Server 创建临时表（如 #rank_temp）时，会立刻在 tempdb 分配数据页、记录日志、维护统计信息；后续 INSERT、CREATE INDEX、JOIN 都触发磁盘 I/O。而 ROW_NUMBER() OVER (PARTITION BY dept_id ORDER BY salary DESC) 的整个过程由优化器调度：排序若不溢出，就在内存完成；编号直接追加到输出行，零中间表、零显式 DDL。
- 查
sys.dm_exec_query_stats可验证：logical_reads和tempdb_allocations通常是临时表方案的 3–8 倍 - 高并发下
tempdb的 PFS/SGAM 页面闩锁争用会成瓶颈，窗口函数天然避开这层 - 临时表需手动
DROP TABLE或依赖会话结束自动清理；窗口函数无生命周期管理成本
窗口函数能复用原表索引，临时表常被迫新建
如果原表已有 (dept_id, salary DESC) 复合索引，ROW_NUMBER() OVER (PARTITION BY dept_id ORDER BY salary DESC) 可直接利用该索引完成分区扫描和有序读取，避免额外排序。而临时表通常要先 SELECT INTO #t 拷贝数据，再对 #t 单独建索引——这一步不仅耗时，且索引统计信息可能不准，导致后续 JOIN 选错执行计划。
- 没索引字段上用
ORDER BY是窗口函数唯一重开销点，但仍是单次排序；临时表方案可能在多个环节重复排序 -
WITH ranked AS (SELECT *, ROW_NUMBER()) SELECT * FROM ranked WHERE rn <= 10仍不落地，只是逻辑命名，不增加tempdb压力
执行计划里没有 Table Spool 就是省资源的关键信号
临时表方案在执行计划中必有 Table Insert、Clustered Index Insert 节点，还常带 Table Spool (Eager Spool)——这代表 SQL Server 主动缓存中间结果，是资源消耗的可视化标志。窗口函数的执行计划则干净得多：Index Scan/Seek → Sort（或 Index Seek + Ordered Prefetch）→ Window Spool（内存结构，非磁盘表）→ Compute Scalar（生成 rn 列）。
-
Window Spool是轻量级内存操作，不计入tempdb_allocations，也不受max server memory外部限制 - 若看到执行计划里出现
Warning: Operator used tempdb to spill data，那一定是Sort溢出了——应检查ORDER BY字段是否有索引，而不是退回去建临时表
真正容易被忽略的是：窗口函数节省的是“重复建上下文”的开销，不是“少算”。哪怕数据量不大，只要执行计划里 Table Insert 和 Clustered Index Scan 连续出现，就是中间表泛滥的明确信号——这时候改写窗口函数，往往比调优索引更立竿见影。
