3

私は、以下がアプリケーションの待ち時間を短縮するための十分に文書化されたパターン (またはそのことについてはアンチパターン) であるかどうかを見つけようとしています。私はこの手法を試してみましたが、これによりレイテンシが 20% 短縮されたように見えます。知っておくべき副作用があるかどうか知りたい

環境：

データベースに対して複数の SELECT 呼び出しを行うメソッド/関数/手順があり、それを最適化する必要があります。

メソッドの流れは次のとおりです。

  getDBConnection()  
  execute("Select a,b from tableA");  
  bind a with varA 
  bind b with varB  
  ---SOME Business Logic-----  
  execute("Select c,d from tableB");  
  bind c with varC  
  bind d with varD   
  ---SOME more Business Logic-----  
  execute("Select e,f from tableC");  
  bind e with varE  
  bind f with varF  
  ---SOME more Business Logic-----  
  releaseConnection()

解決策 : Union ALL を使用してデータベースを 1 回呼び出す

 getDBConnection()
 execute("Select a,b,'sqlA' from tableA"+  
 " UNION ALL "+  
 " Select c,d,'sqlB' from tableB"+  
 " UNION ALL "+
 "Select e,f,'sqlC' from tableC");  
 bind a,b where records have "sqlA"   
 bind c,d where records have "sqlB"
 bind e,f where records have "sqlC"  
 releaseConnection()  
 --------Do all Business Logic here-----
4

2 に答える 2

6

を使用するとunion、クエリの「形状」が制限されます。基本的に、それらはすべて、同じ数と (互換性のある) 型の列を同じ順序で返す必要があります。

より良いアプローチは、1 つのコマンドで複数のクエリを使用してから、複数の結果セットを処理することです。

execute("Select a,b from tableA;"+
  "Select c,d from tableB;"+
  "Select e,f from tableC");

または、これらのクエリを実行する専用のストアド プロシージャを作成することもできます。

これとは別に、この最適化手法は無関係な操作をまとめてしまう可能性があり、後で個々の操作の再利用性が制限されます。これらの操作をより適切に分離し、何らかの方法を使用QueryManagerして最初にそれらを収集し、後でそれらをすべて一緒に実行する設計を検討することをお勧めします。

于 2011-07-07T18:44:23.980 に答える
1

すべてを一緒に押し込むと、本当の問題が見えなくなる可能性があります: レイテンシがどこから来ているか知っていますか?

これらのクエリが何度も呼び出される場合、コンパイル フェーズに多くの時間を費やしている可能性があります。アプリケーションの存続期間中にテーブルが大幅に変更されない場合は、準備済みステートメントを使用すると役立つ場合があります。

conn = connect_to_db()
pstmt = conn.prepare('select ...')
...
pstmt.bind(parameters) // if necessary
pstmt.execute()

待ち時間がコンパイルによるものではない場合、それは実行である可能性があります。指定したクエリは単純な選択ですが、より複雑なものは説明計画の調査を正当化する可能性があります。

dbms とテーブルの構造で許可されている場合は、いくつかの再構築を行うことで、必要なクエリの量を削減することもできます: select ステートメントをユニオンの代わりにジョインと組み合わせることができますか? パーティショニングを使用してテーブルをマージできますか?

以上が一般的なアイデアの集まりです。あなたの実際の質問に答えるために、私は以前にそのアプローチが使用されたのを見たことがありませんが、悪評だけが決定的な要因になることはありません. 前の投稿者が指摘したように、コードの再利用性を犠牲にする可能性があります。最後に、テーブルの数が増えると、このアプローチはうまく拡張できなくなります。アプリケーション コードで「sqlA」、「sqlB」などを含む行を検索する必要があります。

于 2011-07-08T15:31:29.950 に答える