3

バッチ更新の定義とパフォーマンスに関して、これら 3 つのソリューションの違いは何ですか。

1)

Insert into table1 values ('A','A1'),('B','B1'),('C','C1'), ....

2)

Transaction.begin();

insert into table1 values('A','A1'); insert into table1
values('B','B1'); insert into table1 values('C','C1'); ... ... ...

Transaction.commit();

3)

PreparedStatement.addBatch(...);
PreparedStatement.executeBatch();

またはBatch=trueMyBatis構成で設定

4

1 に答える 1

1

データベースが構文 1 を有効なもの (MS-SQL 2008 など) と見なし、#1 と #2 の両方がネイティブ データベースの SQL 実装にあると仮定すると...

次に、質問のパフォーマンス部分について...

#1 は、1 回解析/準備され、単一のアトミック トランザクションとして 1 回実行されるため、最も高速です。

＃2は次のパフォーマンスになります。(txn begin) と (txn end) の 2 つのステートメントと、挿入ごとに 1 つのステートメントがあります。

＃2a（私が提案するもの）はより速く動作します。サーバーでサポートされている構文に応じて、パラメーター化された SQL を「準備」し、各値をパラメーターとして使用して、準備されたステートメントを繰り返し呼び出す (実行する) 場合です。このようにして、実際のステートメントは一度だけ解析されます。例えば 

  Transaction.begin();  
  Stmt.Prepare("insert into table1 values(:Var1, :Var2)");  
  Stmt.Execute('A','A1');  
  Stmt.Execute('B','B1');  
  Stmt.Execute('C','C1');  
  Transaction.commit();

＃3はORMフレームワークに基づいているため、独自のオーバーヘッドがあり、＃1および＃2aよりも遅くなります。ただし、実装方法によっては＃2よりも高速になる可能性があります。まれに、#3 が #1 と #2a の両方よりも高速である可能性があります。「もし」 ORM フレームワークが内部的にそのような繰り返し挿入をデータベース固有の一括読み込み呼び出しに変更するのに十分なほどインテリジェントである場合。

質問のバッチ更新定義部分について...

それも基本的に複数の部分からなる決定です....
#A 主観的な好みの選択です。
#B 目の前の仕事をこなせるか..

私は個人的に #2a が好きです。これは、#1 とほぼ同じくらい高速ですが、より読みやすく、はるかに大きなデータセットを処理できるためです。また、ループに入れて、ストリーム/ファイルなどから値を読み取って挿入することもできます。 、一方 #1 は、特定の DBMS 実装の最大 SQL ステートメント サイズによって制限される場合があります。＃3およびその他のバリエーションは、使用しているORMフレームワークに大きく依存するため、これ以上特定するのは困難です.

これは幅広い質問なので、回答も幅広くしています。具体的に不明な点がある場合は、コメントしてください。喜んで拡大させていただきます。

于 2014-04-23T06:02:05.150 に答える