web-dev-qa-db-ja.com

ストアドプロシージャでは、クエリウィンドウよりクエリの実行速度が遅いのはなぜですか？

クエリウィンドウで2秒で実行される複雑なクエリがありますが、ストアドプロシージャとして約5分です。ストアドプロシージャとして実行するのにそれほど時間がかかるのはなぜですか？

クエリは次のようになります。

特定のレコードセット（@idと@createdDateで識別される）と特定の期間（@startDateから1年間）を受け取り、送信された手紙と支払い予定額の要約リストを返しますそれらの手紙の結果として受け取った。

CREATE PROCEDURE MyStoredProcedure
    @id int,
    @createdDate varchar(20),
    @startDate varchar(20)

 AS
SET NOCOUNT ON

    -- Get the number of records * .7
    -- Only want to return records containing letters that were sent on 70% or more of the records
    DECLARE @limit int
    SET @limit = IsNull((SELECT Count(*) FROM RecordsTable WITH (NOLOCK) WHERE ForeignKeyId = @id AND Created = @createdDate), 0) * .07

    SELECT DateSent as [Date] 
        , LetterCode as [Letter Code]
        , Count(*) as [Letters Sent]
        , SUM(CASE WHEN IsNull(P.DatePaid, '1/1/1753') BETWEEN DateSent AND DateAdd(day, 30, DateSent) THEN IsNull(P.TotalPaid, 0) ELSE 0 END) as [Amount Paid]
    INTO #tmpTable
    FROM (

        -- Letters Table. Filter for specific letters
        SELECT DateAdd(day, datediff(day, 0, LR.DateProcessed), 0) as [DateSent] -- Drop time from datetime
            , LR.LetterCode -- Letter Id
            , M.RecordId -- Record Id
        FROM LetterRequest as LR WITH (NOLOCK)
        INNER JOIN RecordsTable as M WITH (NOLOCK) ON LR.RecordId = M.RecordId
        WHERE ForeignKeyId = @id AND Received = @createdDate
            AND LR.Deleted = 0 AND IsNull(LR.ErrorDescription, '') = ''
            AND LR.DateProcessed BETWEEN @startDate AND DateAdd(year, 1, @startDate)
            AND LR.LetterCode IN ('a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', 'j', 'k', 'l', 'm', 'n', 'o')
    ) as T
    LEFT OUTER JOIN (

        -- Payment Table. Payments that bounce are entered as a negative payment and are accounted for
        SELECT PH.RecordId, PH.DatePaid, PH.TotalPaid
        FROM PaymentHistory as PH WITH (NOLOCK)
            INNER JOIN RecordsTable as M WITH (NOLOCK) ON PH.RecordId = M.RecordId
            LEFT OUTER JOIN PaymentHistory as PR WITH (NOLOCK) ON PR.ReverseOfUId = PH.UID
        WHERE PH.SomeString LIKE 'P_' 
            AND PR.UID is NULL 
            AND PH.DatePaid BETWEEN @startDate AND DateAdd(day, 30, DateAdd(year, 1, @startDate))
            AND M.ForeignKeyId = @id AND M.Created = @createdDate
    ) as P ON T.RecordId = P.RecordId

    GROUP BY DateSent, LetterCode
    --HAVING Count(*) > @limit
    ORDER BY DateSent, LetterCode

    SELECT *
    FROM #tmpTable
    WHERE [Letters Sent] > @limit

    DROP TABLE #tmpTable

最終結果は次のようになります。

日付文字コード文字送信金額支払額
 1/1/2012 a 1245 12345.67 
 1/1/2012 b 2301 1234.56 
 1/1/2012 c 1312 7894.45 
 1/1/2012 a 1455 2345.65 
 1/1/2012 c 3611 3213.21

すべてがクエリエディターで非常に高速に実行されるため、スローダウンがどこにあるのかを理解するのに問題があります。クエリをストアドプロシージャに移動したときだけ、実行に時間がかかります。

クエリ実行プランが生成されることと関係があると確信していますが、SQLについて十分に理解していないため、問題の原因を特定できません。

クエリで使用されるすべてのテーブルには数百万のレコードがあることに注意してください。

クエリエディターよりもストアドプロシージャとして実行するのに時間がかかる理由を誰かに説明してもらえますか？また、ストアドプロシージャとして実行すると、クエリのどの部分がパフォーマンスの問題を引き起こしているのかを特定できますか？

sql-server-2005stored-proceduresperformancequery-performance
14
Rachel

Martinがコメントで指摘 のように、問題は、クエリが、指定されたパラメーターに不適切なキャッシュされたプランを使用していることです。

彼が提供したリンク アプリケーションで遅い、SSMSで速い？パフォーマンスの謎を理解する は、いくつかの解決策につながる多くの有用な情報を提供しました。

私が現在使用している解決策は、パラメーターをプロシージャのローカル変数にコピーすることです。これにより、SQLが実行されるたびにクエリの実行プランが再評価されるため、使用する代わりに、指定されたパラメーターに最適な実行プランが選択されます。クエリに不適切なキャッシュされたプラン。

機能する可能性のある他のソリューションはOPTIMIZE FORまたはRECOMPILEクエリヒント。

5
Rachel

Stackoverflowに関する同様の質問から（ さらに回答あり ）、ストアドプロシージャを確認します。

  • [〜＃〜]悪い[〜＃〜]：SET ANSI_NULLS OFF（5分、6M熱心なスプール）
  • [〜＃〜]良い[〜＃〜]：SET ANSI_NULLS ON（0.5秒）
0
Ian Boyd