2017-01-31 13 views
0

奇妙なパフォーマンスの問題が発生しています。私はCTEに基づいたビューを持っています。私は何年も前に書きましたが、問題なく走っています。突然、4日前に、1〜2分で実行されたクエリーが、長時間実行されたクエリーを特定して停止するまで何時間も実行されました。SQL Server LEFT OUTER JOINクエリのパフォーマンス

CTEは、エージェントが実行するトランザクションのタイムスタンプ付きリストを生成します。次に、CTEからSelectを選択し、後続のトランザクションのタイムスタンプを使用してCTEに戻って参加し、エージェントが各トランザクションに費やす時間を決定します。

WITH [CTE_TABLE] (COLUMNS) AS 
    (
    SELECT [INDEXED COLUMNS] 
     ,[WINDOWED FUNCTION] AS ROWNUM 
    FROM [DB_TABLE] 
    WHERE [EMPLOYEE_ID] = 111213 
    ) 

    SELECT [T1].[EMPLOYEE_ID] 
     ,[T1].[TRANSACTION_NAME] 
     ,[T1].[TIMESTAMP]   AS [START_TIME] 
     ,[T2].[TIMESTAMP]   AS [END_TIME] 
    FROM [CTE_TABLE] [T1] 
     LEFT OUTER JOIN [CTE_TABLE] [T2] ON 
      (
      [T1].[EMPLOYEE_ID] = [T2].[EMPLOYEE_ID] 
      AND [T1].[ROWNUM] = [T2].[ROWNUM] + 1 
      ) 

特定のエージェントをフィルタリングします。 CTEの内部を実行する場合、1秒未満で500個のレコードが生成されます。 (単純なSELECT * FROM [CTE_TABLE]を使用してCTEを実行すると、1秒未満で実行されますが、1つのエージェントでフィルタリングしない場合、14秒で95Kレコードが生成されます。 INNER JOINを使用してそれを実行すると、再び1秒未満で実行されます。最後に、LEFT OUTER JOINとして実行すると、1つのエージェントの500件のレコードに対して1分半を要します。その日の最後のレコードはエージェントのログオフであり、参加するレコードは決してないので、LEFT OUTER JOINが必要です。

私が引っ張っているテーブルは22GBを超えており、500万行もあります。このテーブルのレコードを1日選択するには14秒かかります.1秒未満でエージェントが1つしかないので、パフォーマンスのボトルネックはソーステーブルから来るとは思われません。ボトルネックはLEFT OUTER JOINでCTEに戻ってきますが、私はいつもLEFT OUTER JOINを持っていました。再び、非常に奇妙な側面は、これが4日前に始まったということです。私はサーバー上のスペースをチェックして、たくさんあります。 CPUはおよそにスパイクします。 25%であり、クエリが単独で実行されるか、管理者によって中断されるまでそこに残ります。

私は誰かがこれを引き起こした可能性についていくつかの考えを持っていることを期待しています。それはどこからも切り裂かれているようだ。

+1

実行しているSQL Serverのバージョンは? 2012年を上回っている場合は、LEAD/LAGを使用するのに適しています。 –

答えて

1

ここでも、非常に奇妙な側面は、これが唯一の4日前

私は関与して表に関する統計を更新してもボトルネックが中に発生したインデックス

を再構築しようとお勧めし始めたということです左外部結合でCTEに戻る

CTEは統計情報を持たないため、私はmateralizing t彼はこれが役立つかどうかを確認するためにTempテーブルにCTEを入力してください

+0

インデックスを再構築しました!ありがとうございました!可能であれば、なぜINNER JOIN Vのパフォーマンスに影響を与えたのでしょうか?データのメモリ表現のLEFT OUTER JOIN? – UncleJasper75

+0

ジョインを変更すると、オプティマイザは別のスキャンまたはシークのパスを取るようになります。さらに利用可能な統計に基づいています。 – TheGameiswar

+0

@ UncleJasper75:実行計画を投稿してください。 – TheGameiswar