5

重複の可能性:
複数の INSERT ステートメントと複数の VALUES を持つ単一の INSERT

ブログ投稿のバッチ処理のトランザクションのパフォーマンス分析を行っていますが、バッチ挿入ステートメントを使用すると、同等の個々の SQL ステートメントよりもはるかに遅く実行されることに気付きました。

以下のように1000行を挿入すると、約3秒かかります

INSERT TestEntities (TestDate, TestInt, TestString) VALUES  
('2011-1-1', 11, 'dsxcvzdfdfdfsa'),
('2011-1-1', 11, 'dsxcvzdfdfdfsa'),
('2011-1-1', 11, 'dsxcvzdfdfdfsa')

以下のように 1000 行を挿入すると 130 ミリ秒かかります

INSERT TestEntities (TestDate, TestInt, TestString) VALUES ('2011-1-1', 11, 'dsxcvzdfdfdfsa')
INSERT TestEntities (TestDate, TestInt, TestString) VALUES ('2011-1-1', 11, 'dsxcvzdfdfdfsa')
INSERT TestEntities (TestDate, TestInt, TestString) VALUES ('2011-1-1', 11, 'dsxcvzdfdfdfsa')

これは、テーブルで初めてバッチ挿入を使用したときにのみ発生するように見えますが、再現可能です。

また、挿入するデータはランダムであることに注意してください（ただし、両方のクエリで同じです）

編集：

この場合に使用するダミーのランダムデータを使用した私の再現ケースは次のとおりです: https://gist.github.com/2489133

4

3 に答える 3

3

複数のINSERTステートメントと複数の値を持つ単一のINSERTによると、ここでの問題は、SQLがクエリを取得するときに、最初の実行でクエリプランを計算する必要があることです。単一の挿入の場合、計算する必要があまりないため、これは素晴らしく迅速です。クエリプランを構築した後は、それを 1000 回再利用するだけです。

バッチ シナリオでは、クエリ プランに組み込む必要がある 3,000 の変数があり、計算に時間がかかります。

@MartinSmith が指摘するクレイジーな機能の 1 つは、最大 250 行のバッチ サイズの周りにマジック パフォーマンス ナンバーがあることです。これは、計画の計算が非常に低いことを意味します。

上記のクエリを 5 つの 200 行のステートメントに分割すると、実行時間が 1000 行で 94 ミリ秒に短縮されます

于 2012-04-25T11:56:53.127 に答える
1

最初の項目は、解析する必要がある 1 つの大きなステートメントであるため、そこで費やされる余分な時間は、1000 個の小さな解析ジョブではなく、1 つの大きな解析ジョブのオーバーヘッドになります。

1000 行すべてをテストしたわけではありませんが、3 行をテストしたところ、単一の挿入ステートメントの実行計画の方が大きいことがわかりました。また、3 つの個別の挿入の場合、再利用される小さな計画は 1 つだけであることに注意してください。

ここに画像の説明を入力

ここに画像の説明を入力

于 2012-04-25T11:50:07.603 に答える
0

最初のものは、単一のトランザクションとして実行される単一のステートメントです。2 つ目は、1000 トランザクションのオーバーヘッドを持つ 1000 ステートメントです。begin transaction2つ目をとで囲むと差が小さくなるはずですcommit transaction。

于 2012-04-25T11:46:26.467 に答える