我为一个临时报告编写了一个TSQL查询，该报告读取了一个非常大的表(5亿条记录)，该表在Date/Time上建立了索引(集群)。
查询在某些日期范围内运行得非常慢，而在其他日期范围内运行得非常快。我想弄清楚它为什么会这样。
我取了2组日期范围。一个为(04-03-2014至04-04-2014)，另一个为(05-03-2014至05-04-2014)。基本上两个测试结果相隔一个月。第一个范围是快速的，仅在10秒左右返回，而另一个则永远挂起。
查看数据集，看看是否一个明显大于另一个，我在查询中分析了2个表，作为单元测试每个段的一种形式。TableA是我选择的第一个大数据表。表b是查询后面的连接表，我在表b上左JOIN表a:
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)
Product在查询中使用的[Time]上被索引(Clustered)。Sales在[Users-ID]上连接，这是Sales的非聚集索引(表b)瓶颈看起来是当我在SUBQUERY中加入SALES时。
<<p> 优化/strong>我查看了碎片索引，看看这是否是原因。我注意到产品表有85%的碎片索引，这可能是NON-CLUSTERED的原因。我昨晚重建了，没有变化。Sales表也有一个较小的表，它也被重建了。
重建磁盘上碎片百分比较低的聚集索引。在重建索引之后，我不得不为一个不相关的任务重新启动SQL Server，并且查询在坏日期范围上的运行速度与所有其他范围相同。我将假设修复归因于索引的重建，因为如果相同的查询在其他日期范围内比记录集更大的其他日期范围内更快，那么这是最有意义的。