百万行以上のテーブルがあります。このテーブルは、画像のインデックスを作成するために使用されますtiff。各画像には、などのフィールドがありますdate。numberこれらの画像に500のバッチでインデックスを付けるユーザーがいます。最初に500行を挿入してから、500の更新を実行するか、ユーザーがインデックスを作成し終えたら、すべてのデータを含む500の挿入。非常に重要なことは、最初に500回の挿入を行う場合、前夜に行うことができるため、今回は無料です。
したがって、問題は、挿入または挿入と更新を行う方がよいのか、そしてその理由は何かということです。各画像の値を定義しidました。また、フィールドに他のインデックスもあります。
Sql サーバーでの更新により行がゴースト化されます。つまり、Sql は 1 つの行を消して新しい行を入れます。消された行は後で削除されます。
挿入と更新の両方がこのようにページ分割を引き起こす可能性があります。どちらも効果的にデータを「追加」します。更新が最初に古いものにフラグを立てるだけです。
この更新に加えて、最初に行を検索する必要があります。これは、大量のデータの場合、更新よりも時間がかかる可能性があります。
挿入は、特に順序どおりである場合、または基になるテーブルにクラスター化されたインデックスがない場合は、ほぼ常に高速になります。
大量のデータをテーブルに挿入する場合は、現在のインデックスを確認してください。変更と構築に時間がかかる場合があります。インデックスの途中で値を追加すると、常に遅くなります。
アドレス帳に追加するようなものと考えることができます。Z さんは最後のページに追加できますが、M さんは真ん中にスペースを見つける必要があります。
最初に挿入を行ってから更新を行う方が、いくつかの理由からより良い考えのようです。取引量が少ない時間帯に挿入します。挿入にはより多くのデータがあるため、これを実行するのに適した時期です。
更新に id 値 (おそらくインデックス化されている) を使用しているため、更新のオーバーヘッドは非常に低くなります。また、更新中のデータも少なくなります。
バッチ (500 回の挿入/更新) レベルでトランザクションをオフにして、個々のレコードごとに使用することで、オーバーヘッドを削減することもできます。
最後に、最終的な決定を下す前に、これをテストして、サーバーでの実際のパフォーマンスを確認してください。
これは切り詰めた質問ではありません。クリシュナとガレギアンの指摘は的を射ている。
更新の場合、更新が固定長フィールドに影響を与える場合、影響は軽減されます。varchar または blob フィールドを更新する場合、新しい値が古い値の長さを超えると、更新中にページ分割のコストが追加される場合があります。
挿入はより速く実行されると思います。ルックアップは必要ありません (更新を行うときは、基本的に where 句を使用した選択と同等のことを行います)。また、挿入は更新のように行をロックしないため、テーブルに対して同時に行われている選択を妨げることはありません。
各クエリの実行計画は、どちらがより高価であるべきかを示します。実際の制限要因はディスクへの書き込みであるため、perfmon の実行中にいくつかのテストを実行して、どのクエリがより多くの書き込みを引き起こし、ディスク キューが最も長くなるかを確認する必要がある場合があります (長いほど悪いことです)。
私はデータベースの専門家ではありませんが、更新にはルックアップが必要ですが、挿入には必要ないため、1回のショットで挿入を実行する方が高速になると思います。