我为一个临时报告编写了一个TSQL查询，该报告正在读取一个在日期/时间上被索引（聚集）的非常大的表（5亿条记录）。
查询在某些日期范围内运行速度非常慢，而其他日期范围内的查询速度非常快。我试图找出它为什么这样做。
我拍了2套日期范围。一个用于（04-03-2014至04-04-2014），另一个用于（05-03-2014至05-04-2014）。两个测试结果基本上相隔一个月。第一个范围很快，只需10秒钟左右就可以返回，而另一个范围永远存在。
查看数据集以查看一个数据集是否明显大于另一个数据集，我在查询中分析了2个表，作为对每个段进行单元测试的一种形式。 TableA是我用大数据选择的第一个表。 TableB是稍后查询的连接表，其中我LEAD JOIN TableA ON TableB：
TableA (04-03) = 239,806 Records (1 Second Query Time)
TableB (04-03) = 6,569 Records (0 Second Query Time)
TableA (05-03) = 203,535 Records (8 Second Query Time)
TableB (05-03) = 3,388 Records (0 Second Query Time)
正如您所看到的，04日期月份的TableA比05日期月份的TableA更快，更多记录，记录更少，时间更慢。
现在查询本身，但我正在努力更新它。这是一些伪代码：
CTE Query
SELECT PRODUCTS (TableA - 100K+ Records)
LEFT JOIN PRODUCT TABLE (1K Records)
FILTERED BY [Time], LIKE Statement off LEFT JOIN
SELECT FROM ( --SUBQUERY
SELECT FROM CTE Query
LEFT JOIN SALES (TableB - 1K+ Records)
JOIN ON [User-ID]
)
PIVOT SUBQUERY (18 Columns in Pivot)
产品在[Time]上被索引（Clustered），在查询中使用。 销售加入[Users-ID]，这是销售的非集群指数（表B） 瓶颈看起来是我在SUBQUERY中加入SALES的时候。
优化
我查看了碎片索引，看看是否是原因。我注意到产品表有一个85％的碎片索引可能是非聚集的原因。我昨晚重建了这个，没有变化。 Sales表也有一个较小的重建了。
答案 0 :(得分：0)
重建聚集索引，其中磁盘碎片百分比较低。重建索引后，我不得不重新启动SQL Server以执行不相关的任务，并且查询在错误的日期范围内运行与所有其他范围相同的速度。我将假设修复归因于索引的重建，因为如果相同的查询在其他日期范围内比记录集较大的其他日期范围更快，则最有意义。