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

これがパラメータスニッフィングであることに同意しません。

他のものとは別に、あなたが示したクエリはパラメータを使用していません！

統計を更新する必要があり、新しい行を挿入して最近挿入されたデータをクエリするときに、デフォルトの再コンパイルしきい値では不十分であるという、日付列の昇順に関する一般的な問題が発生している可能性があります。トレースフラグ2389および2390が役立ちます。

引数をとれない述語が統計の使用を妨げないことに少し驚いていましたが、年を調整する次のクエリを使用した簡単なテストから、推定行数に影響があります。

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

パラメータスニッフィングが原因の場合... SP内で、次のことを試してください。

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

    [SP LOGIC]  

END

また、@CJK に 100% 同意します。日付フィルタリングの方法は、インデックスを無効にすることがSARGできないため、インデックスを無効にします。

于 2013-01-11T16:27:12.983 に答える