シナリオをマージします。この表には、個々の顧客に関する価格履歴があり、毎日計算されます。毎日平均600万レコードあります。毎朝、価格リストが生成され、価格設定の変更を反映するためにマージステートメントが実行されます。TSQLパフォーマンス
mergeステートメントは、前日の前のデータが変数テーブルに挿入され、そのテーブルが実際のテーブルにマージされることから始まります。主な問題は、マージステートメントがかなり長くかかることです。
私の本物の質問は、可変テーブル対物理テーブルと一時テーブルの使用のパフォーマンスを中心にしています。このような大規模なマージのベストプラクティスは何ですか？
思考
私は、一時テーブルを検討したい：これらは役立つ統計情報を持っています。テーブル変数は常に1つの行を持つとみなされます。また、IOを別のドライブにシャントすることもできます（別途tempdbがあると仮定して）
トランザクションが1つでも必要ない場合は、MERGEもDELETE、UPDATE、INSERTシーケンスに分割して作業量を減らします各アクションで必要なロールバック情報の量とロックの量を減らす
こんにちは、あなたは少しこれを明らかにすることができます先生。あなたは、T-SQL MERGE操作が同等の3つの個別操作よりも高価であると言っていますか？ –
@ JohnSansom：本当にわからない。しかし、私はJER JFDIパターンhttp://stackoverflow.com/search?q=user%3A27535+JFDIをやっているなら、おそらくMERGEが高価かもしれないことを示唆しているもの（@AaronBertrand？）を読みました。それを言って、私は今SQL Server 2012でたくさんのMERGEを使用していますが、私は何の問題も見ていません – gbn
テーブルにインデックスを付けるかどうかを確認してください。インデックスは、そのテーブルにレコードを追加/削除するたびに更新されます。
レコードをマージする前にインデックスを削除してから、マージ後に再度作成し直してください。
テーブルのインデックスが非常に重いので、インデックスは実際には問題ではありません。マージステートメントはレコードをどこにも挿入せず、主にエクスポートのためにcsvファイルに書き込まれる出力に使用されます。 –
@kaiopur：あなたのステートメントは、 "マージステートメントはレコードをどこにも挿入しません"というメッセージはあなたの質問とは根本的に違うものです。いくつかのコードを投稿する必要があります。 – NotMe
@kaiopur：私の答えを編集しました。 – acermate433s
大量のデータセットの場合、一時テーブルはテーブル変数よりもパフォーマンスが良いことがあります。
6M行のRAMの使用量によっては、SQL Serverがすでにテーブル変数を一時的なテーブルに変換している可能性があります。 –
非常に速い速度で構築されたTLOGを表示します。一部のバッチ削除によってこれを処理しました。 –