0

我有一些查询可以为我提供一组数据。现在，在 2013 年之前，它们根据查询的数据量运行得与预期一样快。但现在它就像地狱一样慢。例子：

SELECT *
FROM   (SELECT TOP 25 UserDetail,
                      isnull(ROUND(SUM(Cost), 2), 0) AS MixedCost
        FROM   PCounter.dbo.PrintJobsWithUserDetail
        WHERE  Month(PrintDate) = 1
               AND Year(PrintDate) = 2013
        GROUP  BY UserDetail
        ORDER  BY MixedCost DESC) AS A
ORDER  BY A.MixedCost ASC

现在，对于 Month = 1 Year = 2012，此查询在 2 秒内执行，而对于 2013，则需要 ¬3 分钟。

我要疯了吗？PS 每个月的数据量都差不多

4

2 回答 2

1

如果参数嗅探是罪魁祸首……在您的 SP 中，请尝试以下操作；

ALTER PROC MyProc
@YearParm INT
AS
BEGIN
    DECLARE @DummyParm INT
    SET @DummyParm = @YearParm

    [SP LOGIC]  

END

另外，我 100% 同意@CJK。日期过滤的方法将否定索引，因为它SARG不能

于 2013-01-11T16:27:12.983 回答
1

我不同意这是参数嗅探。

除此之外，您显示的查询不使用参数！

很可能您的统计信息需要更新，并且您遇到升序日期列的常见问题，即在插入新行然后查询最近插入的数据时默认重新编译阈值不足。跟踪标志 2389 和 2390 可以提供帮助。

我有点惊讶的是，不可分割的谓词不会阻止使用统计信息，但是通过使用以下查询调整年份的快速测试确实会影响估计的行数。

SELECT *
FROM sys.objects
WHERE YEAR(create_date) = 2013
于 2013-01-11T18:45:46.807 回答