我正在编写一个存储过程,它将为销售报告获取数据。查询如下:
INSERT INTO @FirstQuery
SELECT t1.*, t2.*
FROM t1
LEFT JOIN t2 ON t1.idT1 = t2.idT1
LEFT JOIN t3 ON t3.idT2 = t2.idT2
WHERE t1.nonIndexedField = @parameter1
AND (t2.idT2 IS NULL
OR
(@parameter2 = 'XXX' AND t1.indexedField1 = @parameter3)
OR
(@parameter2 = 'YYY' AND t3.indexedField1 = @parameter3)
)使用这些结果,然后填充第二个表变量:
INSERT INTO @SecondQuery
SELECT u1.*, u2.*
FROM u1
INNER JOIN u2 ON u2.idU1 = u1.idU1
WHERE u1.NONindexedField in (SELECT someField FROM @FirstQuery)由于它在QA环境中相当慢,我观察了执行计划。首先,我看了一下预估计划。它发现SecondQuery花了很长时间,我意识到u1.NONindexedField没有索引,估计占总成本的97%。但后来我看了看实际的计划,上面说FirstQuery承担了总成本的100%。我检查了根据估计计划计算的估计行,许多地方估计了很少的行,而实际计划显示的行数约为100 (100K)。我认为这是因为缺少索引的字段位于没有太多行(17K)的表中,但我还是创建了索引。令我惊讶的是,查询时间从500秒减少到15秒。所以,我的问题是...为什么执行计划会有如此大的差异,而实际的计划又是如何偏离的呢?我知道估计计划并不是真正的“对计划的估计”,而是“一个具有估计行数的计划”,但这并不能解释其中的差异,也无法解释为什么实际的计划告诉我所有的成本都在一个不需要优化的查询上……
顺便说一句,我比较了相对时间,第二次查询确实花费了大约97%的总执行时间。
感谢您的阅读!
发布于 2012-04-10 12:26:20
如果实际计划偏离了很远,这可能是由于过时的统计数据造成的。
您是否尝试过更新查询中表的统计信息。
如果统计信息过期,这可能会导致执行计划中断。没有更新的统计数据,您的查询可能会非常低效。
更新统计信息的语法为:
update statistics tablename;尝试更新统计信息,看看是否获得了更准确的执行计划。
https://stackoverflow.com/questions/9916459
复制相似问题