我有一个正在处理数百万条记录的 SQL Server 2008 查询。查询在一个由作业每晚运行的过程中。当我第一次将它放在服务器上时，查询可能需要一整天才能运行，但在一周左右的时间内它会下降到不到一个小时——没有我的任何干预。它以某种方式自我修复。
该查询在 tempdb 中运行，在它自行修复之前，当我检查它的性能统计信息时，我发现以下内容：CXPACKET：20,700 秒或 66% 的等待时间。
PAGEIOLATCH:_SH 2,500 或等待时间的 8%。
LOGBUFFER：1500 秒或等待时间的 5% IO_COMPLETION：1500 秒或等待时间的 5%
我尝试调整索引等，当 CXPACKET 为 77% 的等待时间时，上面的统计数据比我第一次运行时有所改进。我阅读了故障排除技巧，其中说我应该将我的 tempdb 拆分为每个 CPU 的一个文件。我有一个双 cpu 32 位 W2K8 系统，所以我将 tempdb 分成 2 个文件，并将每个文件的大小大大增加到 150 GB，每次 10% 自动增长，但它们没有增长，所以我认为大小足够了。
当我在查询运行时查看服务器时，我可以看到 CPU 没有固定并且徘徊在其容量的 <10% 左右。固定的是DISK IO。机器只有一个磁盘。
事不宜迟，下面是导致问题的两个查询（第一个查询曾经是后者的子查询 - 请参阅下面的解释）：
insert into #ttcbm(tradeId1, tradeId2)
select distinct tp.tradeid tradeId1, tp1.tradeid tradeId2
from #tradeP tp
join #tradeP tp1
on tp.cmbId = tp1.cmbId
and tp.qs_plyrid = tp1.qs_plyrid
and tp.tradeId > tp1.tradeId …