当日期范围较小时，SQL查询需要较长时间？

我有从SQL Server 2000（太旧）表像这样大约10-20万行数据选择一个简单的SELECT语句 -当日期范围较小时，SQL查询需要较长时间？

@startDate = '2014-01-25' -- yyyy-mm-dd 
@endDate = '2014-02-20' 

SELECT 
    Id, 6-7 other columns 
FROM 
    Table1 as t1 
LEFT OUTER JOIN 
    Table2 as t2 ON t1.Code = t2.Code 
WHERE 
    t1.Id = 'G59' -- yes, its a varchar 
    AND (t1.Entry_Date >= @startDate AND t1.Entry_Date < @endDate)

这给了我大约40 K行约10秒。但是，如果我设置@startDate ='2014-01-30'，保持@endDate始终相同，那么查询大约需要2分30秒

要产生相同数量的行，我试着用01-30又花了2分48秒。

我很惊讶地发现差异。我并不期待差异如此之大。相反，我期待它在较短的日期范围内采取相同或更少的时间。

这可能是什么原因以及如何解决？

来源

2014-02-19 Steam

您最近插入和/或删除了大量行吗？这可能是因为表索引上的统计信息已过时，因此查询优化器将在较短的日期范围内进行“索引查找+密钥查找”场景 - 但结果会比仅执行表更慢/聚集索引扫描。我会更新统计数据并再次尝试 - 有什么改进？ –

@marc_s - 我不知道是否有任何行已被插入。这很可能。我不插入任何。我只做提取（ETL）。我仍然在学习，所以我不明白你的意见。我如何更新统计信息？我不是DBA btw。谢谢。 – Steam

[TechNet文章如何更新SQL Server 2000中的统计信息]（http://technet.microsoft.com/en-us/library/aa260645%28v=sql.80%29.aspx） –

您最近插入和/或删除了大量的行吗？这可能是因为表索引上的统计信息已过时，因此查询优化器将在较短的日期范围内进行“索引查找+密钥查找”场景 - 但结果会比仅执行表更慢/聚集索引扫描。

我会建议更新统计数据（请参阅此TechNEt article on how to update the statistics）并再试一次 - 有什么改进？

查询优化器使用统计信息来确定是否快速执行表扫描（只读取所有表的数据页并选择匹配的行），或者在索引中搜索搜索值是否更快;该索引通常不包含所有数据 - 因此，一旦找到匹配项，就需要在表上执行密钥查找以获取数据 - 这是一项昂贵的操作，因此对于小数据集来说只有可行性。如果过时的统计数据“误导”了查询优化器，它可能会选择一个次优的执行计划

来源

2014-03-29 07:23:24

我有一个类似的查询获得“本周”的结果，它非常缓慢。当我使用“dbcc show_statistics”检查统计数据时，它在一周前更新。 “上周”运行速度很快。除此之外，这是否意味着我们需要每周更新统计数据，以便“本周”报告运行速度很快。 “本周”运行缓慢，并有串行流执行计划。 “上周”运行速度很快，并行流执行计划。你能帮忙吗？ – singsuyash

当日期范围较小时，SQL查询需要较长时间？

回答

相关问题