-1

次の問題に取り組むための2つの潜在的な道があります。サーバーの負荷は常に流動的であるため、試してみて、方法論がこのソリューションに報われないことを確認してください。私が持っている2つのアプローチは次のとおりです。 

select *  
from  
  (  
      select foo.a,bar.b,baz.c  
      from foo,bar,baz
      -- updated for clarity sake  
      where foo.a=b.bar  
      and  b.bar=baz.c  
  )  
group by a,b,c

副 

create table results as
select foo.a,bar.b,baz.c  
from foo,bar,baz  
where foo.a=b.bar  
and  b.bar=baz.c ;  

create index results_spanning on results(a,b,c);  

select * from results group by a,b,c;

したがって、明確でない場合に備えて。一番上のクエリは、複数テーブルの選択に対して完全にgroup byを実行するため、インデックスを使用できません。2番目のクエリを使用すると、クエリの結果を格納する新しいテーブルを作成し、スパニングインデックスの作成に進み、クエリごとにグループ化してインデックスを利用できます。

これら2つのアプローチの複雑さの違いは何ですか。つまり、どのようにスケーリングするか、そして大量のデータの場合にどちらが望ましいかです。また、主な問題は全体的な選択のパフォーマンスであるため、ここで修正しようとしています。

コメントコメント

本当に3つのテーブルでCROSSJOINを実行していますか？これらの3つの列は、それ自体でインデックスが付けられていますか？最終結果を提供するクエリをどのくらいの頻度で実行しますか？

1）いいえ
。2）はい。これは明らかに非常に些細な例であるため、説明のために句を省略しました
。3）関係ありません。

2回目の更新

これは一時的なテーブルであり、一時的にのみ有効であるため、はい、このテーブルは1回だけ照会されます。

4

2 に答える 2

0

だから問題は、どちらが速いのかということです。

  1. クエリを1回実行し、結果セットを並べ替えますか？

  2. クエリを1回実行してテーブルを作成し、次にインデックスを作成してから、クエリを再度実行して結果セットを並べ替えますか？

うーん。トリッキーなもの。

Oracleでは、一時テーブルの使用例は非常にまれです。これらは通常、結果セットをフリーズする必要がある場合にのみ適用され、結果セットを繰り返しクエリします。ここでは明らかにそうではありません。

したがって、最初のオプションを選択し、必要に応じてクエリを調整します。

答えは、チューニングの質問でよくあることですが、状況によって異なります。

そもそもなぜGROUPBYをやっているのですか。投稿したクエリは集計を行わないため、GROUP BY woudlを実行する唯一の理由は、重複する行を削除すること、つまりDISTINCT操作です。これが実際に当てはまる場合は、何らかの形式のデカルト結合を実行し、クエリを調整する1つは、WHERE句を修正して、個別のレコードのみを返すようにすることです。

于 2013-01-25T16:14:27.867 に答える
0

クエリが頻繁に実行され、許容できないほど遅い場合は、結果を事前に計算するためにマテリアライズドビューの作成を検討できます。これにより、毎回テーブルを作成するオーバーヘッドなしに、インデックス可能な「テーブル」の利点が得られます。

fastマテリアライズド・ビュー（できればテーブルが大きい場合）を更新する必要がありon commitますon demand。コミット時に作成する方法にはいくつかの制限があり、高速で更新可能なビューがあり、コミット時間の処理にわずかに追加されますが、基本クエリの実行と常に同じ結果が得られます。オンデマンドMVは、基になるデータが更新されるまで変更されるため、古くなります。これが許容できるかどうかを判断する必要があります。

于 2013-01-25T16:36:39.160 に答える