SQL Server 2008 R2で毎晩レポートを作成する必要があります。レポートの計算には数時間かかります。時間を短縮するために、テーブルを事前計算します。このテーブルは、12個の非常に大きな(数千万行)テーブルを結合することに基づいて作成されます。
この集計テーブルの計算には、数日前まで約4時間かかりました。私たちのDBAは、この大きな結合を3つの小さな結合(それぞれ4つのテーブルを結合)に分割しました。一時的な結果は毎回一時テーブルに保存され、次の結合で使用されます。
DBA機能拡張の結果、集計テーブルは15分で計算されます。どうしてそんなことができるのかしら。これは、サーバーが処理する必要のあるデータの数が少ないためです。つまり、元の大きな結合では、合計された小さな結合よりも多くのデータをサーバーで処理する必要があります。ただし、オプティマイザが元の大きな結合を使用して効率的に処理し、結合を独自に分割して、次の結合に必要な数の列のみを送信すると思います。
彼が行ったもう1つのことは、一時テーブルの1つにインデックスを作成したことです。ただし、もう一度、必要に応じてオプティマイザが適切なハッシュテーブルを作成し、全体として計算をより最適化すると思います。
これについてはDBAと話しましたが、処理時間の改善の理由については彼自身も確信が持てませんでした。彼は、そのようなビッグデータを計算するのは圧倒的である可能性があるのでサーバーを非難せず、オプティマイザが最適な実行計画を予測するのに苦労する可能性があることを述べました。これは理解していますが、正確な理由について、より明確な答えを知りたいと思います。
したがって、質問は次のとおりです。
何が大きな改善を引き起こす可能性がありますか?
大きな結合を小さなものに分割する標準的な手順ですか?
複数の小さな結合の場合、サーバーが処理する必要のあるデータの量は本当に少ないのですか?
元のクエリは次のとおりです。
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;
1中間/後期結合のより良い統計と相まって、「検索スペース」の削減。
クエリプロセッサがプランの作成さえ拒否した90テーブルの結合(ミッキーマウスのデザイン)に対処する必要がありました。このような結合をそれぞれ9つのテーブルの10個のサブ結合に分割すると、各結合の複雑さが劇的に低下し、テーブルを追加するたびに指数関数的に増加します。さらに、クエリオプティマイザーはそれらを10のプランとして扱い、全体的に(潜在的に)より多くの時間を費やします(ポールホワイトにもメトリックがあるかもしれません!)。
中間結果テーブルには独自の新鮮な統計が含まれるようになるため、早い段階でゆがみ、すぐにサイエンスフィクションとして終わるディープツリーの統計に比べて、はるかにうまく結合されます。
さらに、最も選択的な結合を最初に強制して、ツリーを上に移動するデータ量を減らすことができます。オプティマイザーよりもはるかに優れた述語の選択性を推定できる場合は、結合順序を強制しないでください。 「ふさふさした計画」を検索する価値があるかもしれません。
2効率とパフォーマンスが重要である場合、それは考慮すべきです
必ずしもそうではありませんが、最も選択的な結合が早い段階で実行された場合である可能性があります
まあ、私はあなたが小さなデータで作業していると言って始めましょう-数千万は大きくありません。ファクトテーブルに4億行追加した最後のDWHプロジェクト。 1日あたり。 5年間の保管。
問題は部分的にハードウェアです。大規模な結合では一時領域が大量に使用され、RAMが非常に少ないため、ディスクにオーバーフローする瞬間は非常に遅くなります。そのため、SQLはセットの世界に存在し、サイズを気にしない一方で、実行するサーバーは無限ではないため、作業をより小さな部分に分割することは理にかなっています。一部の操作中に64GBのtempdbで領域不足エラーが発生することがよくあります。
それ以外の場合は、統計が適切である限り、クエリオプティマイザーに負荷がかかりません。それはテーブルがどれほど大きいかを本当に気にしません-それは本当に成長しない統計によって機能します。それは言った:あなたが本当に大きなテーブル(二桁の十億の行数)を持っているなら、それらは少し粗いかもしれません。
また、ロックの問題もあります。大規模な結合がテーブルを何時間もロックする可能性があることをプログラムでプログラミングしない限りです。私は現在200 GBのコピー操作を行っており、ロックを大幅に短くするビジネスキー(実質的にループ)によってそれらをsmllerpartyに分割しています。
最後に、限られたハードウェアで作業します。