web-dev-qa-db-ja.com

多数の結合を持つSQLクエリを小さいものに分割すると役立ちますか？

SQL Server 2008 R2で毎晩レポートを作成する必要があります。レポートの計算には数時間かかります。時間を短縮するために、テーブルを事前計算します。このテーブルは、12個の非常に大きな（数千万行）テーブルを結合することに基づいて作成されます。

この集計テーブルの計算には、数日前まで約4時間かかりました。私たちのDBAは、この大きな結合を3つの小さな結合（それぞれ4つのテーブルを結合）に分割しました。一時的な結果は毎回一時テーブルに保存され、次の結合で使用されます。

DBA機能拡張の結果、集計テーブルは15分で計算されます。どうしてそんなことができるのかしら。これは、サーバーが処理する必要のあるデータの数が少ないためです。つまり、元の大きな結合では、合計された小さな結合よりも多くのデータをサーバーで処理する必要があります。ただし、オプティマイザが元の大きな結合を使用して効率的に処理し、結合を独自に分割して、次の結合に必要な数の列のみを送信すると思います。

彼が行ったもう1つのことは、一時テーブルの1つにインデックスを作成したことです。ただし、もう一度、必要に応じてオプティマイザが適切なハッシュテーブルを作成し、全体として計算をより最適化すると思います。

これについてはDBAと話しましたが、処理時間の改善の理由については彼自身も確信が持てませんでした。彼は、そのようなビッグデータを計算するのは圧倒的である可能性があるのでサーバーを非難せず、オプティマイザが最適な実行計画を予測するのに苦労する可能性があることを述べました。これは理解していますが、正確な理由について、より明確な答えを知りたいと思います。

したがって、質問は次のとおりです。

  1. 何が大きな改善を引き起こす可能性がありますか？

  2. 大きな結合を小さなものに分割する標準的な手順ですか？

  3. 複数の小さな結合の場合、サーバーが処理する必要のあるデータの量は本当に少ないのですか？

元のクエリは次のとおりです。

    Insert Into FinalResult_Base
SELECT       
    TC.TestCampaignContainerId,
    TC.CategoryId As TestCampaignCategoryId,
    TC.Grade,
    TC.TestCampaignId,    
    T.TestSetId
    ,TL.TestId
    ,TSK.CategoryId
    ,TT.[TestletId]
    ,TL.SectionNo
    ,TL.Difficulty
    ,TestletName = Char(65+TL.SectionNo) + CONVERT(varchar(4),6 - TL.Difficulty) 
    ,TQ.[QuestionId]
    ,TS.StudentId
    ,TS.ClassId
    ,RA.SubjectId
    ,TQ.[QuestionPoints] 
    ,GoodAnswer  = Case When TQ.[QuestionPoints] Is null Then 0
                      When TQ.[QuestionPoints] > 0 Then 1 
                      Else 0 End
    ,WrongAnswer = Case When TQ.[QuestionPoints] = 0 Then 1 
                      When TQ.[QuestionPoints] Is null Then 1
                     Else 0 End
    ,NoAnswer    = Case When TQ.[QuestionPoints] Is null Then 1 Else 0 End
    ,TS.Redizo
    ,TT.ViewCount
    ,TT.SpentTime
    ,TQ.[Position]  
    ,RA.SpecialNeeds        
    ,[Version] = 1 
    ,TestAdaptationId = TA.Id
    ,TaskId = TSK.TaskId
    ,TaskPosition = TT.Position
    ,QuestionRate = Q.Rate
    ,TestQuestionId = TQ.Guid
    ,AnswerType = TT.TestletAnswerTypeId
FROM 
    [TestQuestion] TQ WITH (NOLOCK)
    Join [TestTask] TT WITH (NOLOCK)            On TT.Guid = TQ.TestTaskId
    Join [Question] Q WITH (NOLOCK)         On TQ.QuestionId =  Q.QuestionId
    Join [Testlet] TL WITH (NOLOCK)         On TT.TestletId  = TL.Guid 
    Join [Test]     T WITH (NOLOCK)         On TL.TestId     =  T.Guid
    Join [TestSet] TS WITH (NOLOCK)         On T.TestSetId   = TS.Guid 
    Join [RoleAssignment] RA WITH (NOLOCK)  On TS.StudentId  = RA.PersonId And RA.RoleId = 1
    Join [Task] TSK WITH (NOLOCK)       On TSK.TaskId = TT.TaskId
    Join [Category] C WITH (NOLOCK)     On C.CategoryId = TSK.CategoryId
    Join [TimeWindow] TW WITH (NOLOCK)      On TW.Id = TS.TimeWindowId 
    Join [TestAdaptation] TA WITH (NOLOCK)  On TA.Id = TW.TestAdaptationId
    Join [TestCampaign] TC WITH (NOLOCK)        On TC.TestCampaignId = TA.TestCampaignId 
WHERE
    T.TestTypeId = 1    -- eliminuji ankety 
    And t.ProcessedOn is not null -- ne vsechny, jen dokoncene
    And TL.ShownOn is not null
    And TS.Redizo not in (999999999, 111111119)
END;

DBAのすばらしい仕事の後の新しい分割結合：

    SELECT       
    TC.TestCampaignContainerId,
    TC.CategoryId As TestCampaignCategoryId,
    TC.Grade,
    TC.TestCampaignId,    
    T.TestSetId
    ,TL.TestId
    ,TL.SectionNo
    ,TL.Difficulty
    ,TestletName = Char(65+TL.SectionNo) + CONVERT(varchar(4),6 - TL.Difficulty) -- prevod na A5, B4, B5 ...
    ,TS.StudentId
    ,TS.ClassId
    ,TS.Redizo
    ,[Version] = 1 -- ? 
    ,TestAdaptationId = TA.Id
    ,TL.Guid AS TLGuid
    ,TS.TimeWindowId
INTO
    [#FinalResult_Base_1]
FROM 
    [TestSet] [TS] WITH (NOLOCK)
    JOIN [Test] [T] WITH (NOLOCK) 
        ON [T].[TestSetId] = [TS].[Guid] AND [TS].[Redizo] NOT IN (999999999, 111111119) AND [T].[TestTypeId] = 1 AND [T].[ProcessedOn] IS NOT NULL
    JOIN [Testlet] [TL] WITH (NOLOCK)
        ON [TL].[TestId] = [T].[Guid] AND [TL].[ShownOn] IS NOT NULL
    JOIN [TimeWindow] [TW] WITH (NOLOCK)
        ON [TW].[Id] = [TS].[TimeWindowId] AND [TW].[IsActive] = 1
    JOIN [TestAdaptation] [TA] WITH (NOLOCK)
        ON [TA].[Id] = [TW].[TestAdaptationId] AND [TA].[IsActive] = 1
    JOIN [TestCampaign] [TC] WITH (NOLOCK)
        ON [TC].[TestCampaignId] = [TA].[TestCampaignId] AND [TC].[IsActive] = 1
    JOIN [TestCampaignContainer] [TCC] WITH (NOLOCK)
        ON [TCC].[TestCampaignContainerId] = [TC].[TestCampaignContainerId] AND [TCC].[IsActive] = 1
    ;

 SELECT       
    FR1.TestCampaignContainerId,
    FR1.TestCampaignCategoryId,
    FR1.Grade,
    FR1.TestCampaignId,    
    FR1.TestSetId
    ,FR1.TestId
    ,TSK.CategoryId AS [TaskCategoryId]
    ,TT.[TestletId]
    ,FR1.SectionNo
    ,FR1.Difficulty
    ,TestletName = Char(65+FR1.SectionNo) + CONVERT(varchar(4),6 - FR1.Difficulty) -- prevod na A5, B4, B5 ...
    ,FR1.StudentId
    ,FR1.ClassId
    ,FR1.Redizo
    ,TT.ViewCount
    ,TT.SpentTime
    ,[Version] = 1 -- ? 
    ,FR1.TestAdaptationId
    ,TaskId = TSK.TaskId
    ,TaskPosition = TT.Position
    ,AnswerType = TT.TestletAnswerTypeId
    ,TT.Guid AS TTGuid

INTO
    [#FinalResult_Base_2]
FROM 
    #FinalResult_Base_1 FR1
    JOIN [TestTask] [TT] WITH (NOLOCK)
        ON [TT].[TestletId] = [FR1].[TLGuid] 
    JOIN [Task] [TSK] WITH (NOLOCK)
        ON [TSK].[TaskId] = [TT].[TaskId] AND [TSK].[IsActive] = 1
    JOIN [Category] [C] WITH (NOLOCK)
        ON [C].[CategoryId] = [TSK].[CategoryId]AND [C].[IsActive] = 1
    ;    

DROP TABLE [#FinalResult_Base_1]

CREATE NONCLUSTERED INDEX [#IX_FR_Student_Class]
ON [dbo].[#FinalResult_Base_2] ([StudentId],[ClassId])
INCLUDE ([TTGuid])

SELECT       
    FR2.TestCampaignContainerId,
    FR2.TestCampaignCategoryId,
    FR2.Grade,
    FR2.TestCampaignId,    
    FR2.TestSetId
    ,FR2.TestId
    ,FR2.[TaskCategoryId]
    ,FR2.[TestletId]
    ,FR2.SectionNo
    ,FR2.Difficulty
    ,FR2.TestletName
    ,TQ.[QuestionId]
    ,FR2.StudentId
    ,FR2.ClassId
    ,RA.SubjectId
    ,TQ.[QuestionPoints] -- 1+ good, 0 wrong, null no answer
    ,GoodAnswer  = Case When TQ.[QuestionPoints] Is null Then 0
                      When TQ.[QuestionPoints] > 0 Then 1 -- cookie
                      Else 0 End
    ,WrongAnswer = Case When TQ.[QuestionPoints] = 0 Then 1 
                      When TQ.[QuestionPoints] Is null Then 1
                     Else 0 End
    ,NoAnswer    = Case When TQ.[QuestionPoints] Is null Then 1 Else 0 End
    ,FR2.Redizo
    ,FR2.ViewCount
    ,FR2.SpentTime
    ,TQ.[Position] AS [QuestionPosition]  
    ,RA.SpecialNeeds -- identifikace SVP        
    ,[Version] = 1 -- ? 
    ,FR2.TestAdaptationId
    ,FR2.TaskId
    ,FR2.TaskPosition
    ,QuestionRate = Q.Rate
    ,TestQuestionId = TQ.Guid
    ,FR2.AnswerType
INTO
    [#FinalResult_Base]
FROM 
    [#FinalResult_Base_2] FR2
    JOIN [TestQuestion] [TQ] WITH (NOLOCK)
        ON [TQ].[TestTaskId] = [FR2].[TTGuid]
    JOIN [Question] [Q] WITH (NOLOCK)
        ON [Q].[QuestionId] = [TQ].[QuestionId] AND [Q].[IsActive] = 1

    JOIN [RoleAssignment] [RA] WITH (NOLOCK)
        ON [RA].[PersonId] = [FR2].[StudentId]
        AND [RA].[ClassId] = [FR2].[ClassId] AND [RA].[IsActive] = 1 AND [RA].[RoleId] = 1

    drop table #FinalResult_Base_2;

    truncate table [dbo].[FinalResult_Base];
    insert into [dbo].[FinalResult_Base] select * from #FinalResult_Base;

    drop table #FinalResult_Base;
sql-serveroptimizationjoin
19
Ondrej Peterka

1中間/後期結合のより良い統計と相まって、「検索スペース」の削減。

クエリプロセッサがプランの作成さえ拒否した90テーブルの結合（ミッキーマウスのデザイン）に対処する必要がありました。このような結合をそれぞれ9つのテーブルの10個のサブ結合に分割すると、各結合の複雑さが劇的に低下し、テーブルを追加するたびに指数関数的に増加します。さらに、クエリオプティマイザーはそれらを10のプランとして扱い、全体的に（潜在的に）より多くの時間を費やします（ポールホワイトにもメトリックがあるかもしれません！）。

中間結果テーブルには独自の新鮮な統計が含まれるようになるため、早い段階でゆがみ、すぐにサイエンスフィクションとして終わるディープツリーの統計に比べて、はるかにうまく結合されます。

さらに、最も選択的な結合を最初に強制して、ツリーを上に移動するデータ量を減らすことができます。オプティマイザーよりもはるかに優れた述語の選択性を推定できる場合は、結合順序を強制しないでください。 「ふさふさした計画」を検索する価値があるかもしれません。

2効率とパフォーマンスが重要である場合、それは考慮すべきです

必ずしもそうではありませんが、最も選択的な結合が早い段階で実行された場合である可能性があります

12
John Alan
  1. SQLServerオプティマイザは通常、適切に機能します。ただし、その目的は、可能な限り最良の計画を生成することではなく、十分に迅速な計画を見つけることです。結合が多い特定のクエリでは、パフォーマンスが非常に低下する可能性があります。このようなケースの良い兆候は、実際の実行プランの推定行数と実際の行数の大きな違いです。また、最初のクエリの実行プランには、「結合結合」よりも遅い多くの「ネストされたループ結合」が表示されることは確かです。後者では、両方の入力を同じキーを使用してソートする必要があり、コストがかかります。通常、オプティマイザはそのようなオプションを破棄します。結果を一時テーブルに格納し、結果と同じように適切なインデックスを追加します-私の推測-さらに結合するためのより良いアルゴリズムを選択すること（付記-最初に一時テーブルに入力し、その後にインデックスを追加することにより、ベストプラクティスに従います）。さらに、SQLServerは一時テーブルの統計を生成して保持します。これは、適切なインデックスの選択にも役立ちます。
  2. 結合の数が一定数よりも多い場合の一時テーブルの使用に関する標準があるとは言えませんが、これは間違いなくパフォーマンスを改善できるオプションです。それは頻繁には起こりませんが、私は何度か同じような問題（そして同じような解決策）を経験しました。または、自分で最良の実行計画を考え出し、それを保存して強制的に再利用することもできますが、それには非常に時間がかかります（100％成功することは保証されません）。もう1つの注意点-一時テーブルに格納されている結果セットが比較的小さい場合（たとえば、約10kレコード）、テーブル変数のパフォーマンスは一時テーブルよりも優れています。
  3. 「依存する」とは言いたくないのですが、おそらく3つ目の質問に対する私の答えです。オプティマイザは結果を高速に提供する必要があります。最良の計画を見つけ出すために何時間も費やしたくないでしょう。結合するたびに余分な作業が追加され、オプティマイザが「混乱する」ことがあります。
7
a1ex07

まあ、私はあなたが小さなデータで作業していると言って始めましょう-数千万は大きくありません。ファクトテーブルに4億行追加した最後のDWHプロジェクト。 1日あたり。 5年間の保管。

問題は部分的にハードウェアです。大規模な結合では一時領域が大量に使用され、RAMが非常に少ないため、ディスクにオーバーフローする瞬間は非常に遅くなります。そのため、SQLはセットの世界に存在し、サイズを気にしない一方で、実行するサーバーは無限ではないため、作業をより小さな部分に分割することは理にかなっています。一部の操作中に64GBのtempdbで領域不足エラーが発生することがよくあります。

それ以外の場合は、統計が適切である限り、クエリオプティマイザーに負荷がかかりません。それはテーブルがどれほど大きいかを本当に気にしません-それは本当に成長しない統計によって機能します。それは言った：あなたが本当に大きなテーブル（二桁の十億の行数）を持っているなら、それらは少し粗いかもしれません。

また、ロックの問題もあります。大規模な結合がテーブルを何時間もロックする可能性があることをプログラムでプログラミングしない限りです。私は現在200 GBのコピー操作を行っており、ロックを大幅に短くするビジネスキー（実質的にループ）によってそれらをsmllerpartyに分割しています。

最後に、限られたハードウェアで作業します。

5
TomTom