web-dev-qa-db-ja.com

複数のUNIONを持つストアドプロシージャは、すべてのSQLを並行して実行するよりも効率的ですか?

ストアドプロシージャに以下があります

if
 then

    SELECT TABLE1.COLUMN1,TABLE1.COLUMN2,TABLE1.COLUMN3,TABLE1.COLUMN4 FROM TABLE1,TABLE2 where criteria1 (covers functionality 1)
    UNION
    SELECT TABLE1.COLUMN1,TABLE1.COLUMN2,TABLE1.COLUMN3,TABLE1.COLUMN4 FROM TABLE1,TABLE3 where criteria2 (covers functionality 2)
    UNION
    SELECT TABLE1.COLUMN1,TABLE1.COLUMN2,TABLE1.COLUMN3,TABLE1.COLUMN4 FROM TABLE1,TABLE4 where criteria3 (covers functionality 3)
elseif
 then

    SELECT TABLE1.COLUMN1,TABLE1.COLUMN2,TABLE1.COLUMN3,TABLE1.COLUMN4 FROM TABLE1,TABLE5 where criteria4 (covers functionality 4)
    UNION
    SELECT TABLE1.COLUMN1,TABLE1.COLUMN2,TABLE1.COLUMN3,TABLE1.COLUMN4 FROM TABLE1,TABLE6 where criteria5 (covers functionality 5)
    UNION
    SELECT TABLE1.COLUMN1,TABLE1.COLUMN2,TABLE1.COLUMN3,TABLE1.COLUMN4 FROM TABLE1,TABLE7 where criteria6 (covers functionality 6)

これらのSQLを個別に(並列に)実行してから、結果をセットに入れる(一意のみを取得する)のは良い考えですか?

理論的には理解したいのですが、今は見えないものがありますか?

SQLは別個のDB2ストアード・プロシージャーであるため、内部でそれらをすでに並行して実行している可能性があります。

1
Vipin

アプリケーションからクエリを並行して実行し、出力を結合することは、データベースから調整されたクエリを実行するほど速くはありません。

最も適切な場所で作業を行う

データベースエンジンは、データセットを操作するように設計および最適化されています。確かに、一部のデータベースエンジンは他のエンジンよりも効率的ですが、これが主要なタスクです。外部キー参照を使用するだけで、データベースは2つのテーブルを接続する(それらを結合する)パフォーマンスを何桁も向上させることができます。

クライアントよりもデータベースよりも高速に実行できるものを表示できる場合でも、データをネットワークパイプに移動するのにかかる時間を考慮する必要があります。必要な1または2にフィルターするためだけに、100Kレコードをクライアントに移動するのは簡単です。

ネットワークを介して大量のデータセットを送信すると、ネットワークを使用する他のアプリケーションのパフォーマンスにも悪影響を及ぼします。

4
Adam Zuckerman

すべてのデータが同じテーブルから取得されるため、これはユニオンの奇妙な使用法です。

代わりに、より複雑なwhereステートメントを使用して単一の選択を行うことができます。

今!一方が他方よりもパフォーマンスが高いかどうかは、where句に依存すると思います。

それらをparralellで実行する意味がわかりませんか?コードから呼び出し、結果を反復しますか?データベースとは異なるサーバーでコードを実行している場合、これはよりスケーラブルになります

0
Ewan

パフォーマンスに関しては、並列実行が向上しますが、コードに関しては、ストアドプロシージャ内のすべてをユニオンに配置する方がよい場合があります。

将来、変更が必要な場合(たとえば、他のテーブルを結合することによってフェッチされたデータの更新)、またはクエリに追加された他の3〜4個のユニオンを言う場合。次に、ストアドプロシージャ/クエリを頻繁に呼び出すコードをリファクタリングする必要があります。

0
Learner_101

単一のSELECTを使用して、より複雑なWHERE句を使用する方が、設計の点でより良い代替案であると思います。

また、データベースが重複を排除する必要があるため、偶然にもUNIONアプローチが遅くなることも予想されます。代わりにUNION ALLを使用している場合、どの代替案の方がパフォーマンスが優れているかを推測することはできません(測定する必要があります)。

0
James Youngman