私は1ミリオン以上の行を持つテーブルを持っています。この表はtiffの画像を索引付けするために使用されます。各画像にはdate,numberなどのフィールドがあります。これらの画像には500のバッチでインデックスを作成するユーザーがいます。まず500行を挿入してから500回の更新を実行するか、ユーザーがインデックス作成を完了したらすべてのデータを500個挿入します。非常に重要なことは、私が最初に500個のインサートをすると、前回の夜にそれをすることができるので、この時間は私にとって無料であるということです。挿入コストとSQL Serverの更新
問題は次のとおりです。挿入や挿入や更新を行う方が良いのはなぜですか？なぜですか？私は各画像のためにidの値を定義しました。また、フィールドには他のインデックスもあります。
Sqlサーバーの更新によって、ゴーストされた行が生成されます。つまり、Sqlは1つの行を横切り、新しい行を入れます。後で削除される行は、後で削除されます。
両方の挿入と更新がこの方法でページ分割を引き起こす可能性があり、両者は効果的にデータを追加します。
このアップデートでは、最初にローを検索する必要があります。これは、多くのデータではアップデートよりも時間がかかることがあります。
挿入物は、特に順序が整っている場合や、基になるテーブルにクラスタード・インデックスがない場合は、いつもより速くなります。
テーブルに大量のデータを挿入すると、現在のインデックスが表示されます。変更やビルドには時間がかかることがあります。索引の途中で値を追加する方が常に遅くなります。
あなたは、アドレス帳に追加するように考えることができ：ミスターZはちょうどあなたが氏M.
私はデータベースの人ではありませんが、挿入が行われていない間に更新が検索を必要とするため、ワンショットでの挿入を高速化すると思います。
いくつかの理由から挿入物を先に実行してから更新する方が良い考えです。トランザクション量の少ない時間に挿入されます。インサートにはより多くのデータがあるので、これは良いタイミングです。
更新のためにid値（おそらく索引付けされている）を使用しているため、更新のオーバーヘッドは非常に低くなります。更新中のデータも少なくなります。
バッチ（500個の挿入/更新）レベルでトランザクションをオフにして個々のレコードに使用することで、オーバーヘッドを減らすこともできます。
最後に、これをテストして最終決定を下す前にサーバーの実際のパフォーマンスを確認します。
各クエリの実行計画は、どれが高価であるべきかを示します。実際の制限要因はディスクへの書き込みになります。したがって、perfmonを実行している間にいくつかのテストを実行して、より多くの書き込みが行われ、ディスクキューが長くなる（長くなる）ことがあります。
これは切れても乾燥した質問ではありません。クリシュナとガレニアのポイントが揃っています。
更新プログラムの場合、更新プログラムが固定長フィールドに影響を与える場合、その影響は軽減されます。 varcharまたはblobフィールドを更新する場合は、新しい値が古い値の長さを超えると、更新中にページ分割のコストを追加することができます。
私は挿入がより速く実行されると思います。それらは参照を必要としません（更新を行うときは、基本的にwhere句を使った選択と同等です）。また、インサートは、更新と同じように行をロックしないので、同時にテーブルに対して起こっている選択を妨げません。
ジョバンニのために途中でスペースを見つける必要があるでしょうが、それはまた意志、最後のページに追加することができますインデックス作成（クラスタ化または非クラスタ化）やフィルファクタなどの他の問題に依存します。あなたの特定の状況は、どのように進行するかに大きく寄与します。 – Galwegian