2009-08-19 14 views
2

多くの列(多分100+以上)を含む表が(実際にはいくつか)あります。いくつかの列だけが変更されている場合は、テーブル内の行を更新するときにパフォーマンスが最適です。多くの列を含む表の行を更新する

  1. 変更された列のみを動的に更新するためにUPDATEステートメントを構築します。
  2. 変更されていない列を含む、すべての列を含むパラメータ化UPDATE文を作成する。
  3. ALL値をパラメータとして使用して行を更新するプロシージャを作成するには

私はSQL Serverを使用しています。テーブルにBLOBSはありません。

ありがとう/ M

+0

100以上の列を持つテーブルにはどのような種類のデータを保存しますか? –

+0

実際に私は列の数を数えませんでしたが、多くの列があります。データモデルは問題ありません。テーブルが表すエンティティには多くのプロパティがあります。 –

答えて

1

オプション2と3では、更新時にサーバーに送信されるデータが増えるため、データだけで通信オーバヘッドが大きくなります。

各行には異なる更新された列のセットがありますか、または特定の実行で同じ列の列が更新されていますか(実行時に変更される可能性があります)

後者の場合(特定の実行で同じ列の列が更新されます)、オプション1のほうがパフォーマンスが向上します。ステートメントは一度作成され、何度も使用され、更新ごとにサーバーに最小限のデータが転送されます。

前者のケースでは、変更された列のサブセットが比較的小さいかどうかを調べることにします(たとえば、10行は異なる行で変更されます。 10)。その場合、おそらく単一の準備されたステートメントの便宜のために変更されていない7〜9列の値を送信する比較的小さなオーバーヘッドを受け入れて、10個の列に対してパラメータ化することになります。更新された列のセットがマップ全体にある場合(100個の列のうち50個以上が操作全体にわたって更新されているとします)、ロット全体を処理するだけで簡単です。

ホスト言語(クライアントAPI)が更新をパラメータ化するさまざまな方法をどれほど簡単に処理できるかによって、ある程度までは異なります。

4

数字2と3はパフォーマンスの観点からは同等です。 PKを使用して更新する行を特定し、それがクラスタ化されたキーである場合は、列自体を更新することについては心配しません。第1の状況の問題は、「プロシージャ・キャッシュの膨らみ」が発生することです。プランのキャッシュが膨大になるのは、更新プログラムが少しずつ異なるためです。私は、pに投票したい

あなたが大規模なアップデートを行う上で計画している場合、私はなど、それがFKルックアップを引き起こす可能性があるため、すべての列の更新をお勧めすることを躊躇かもしれません

おかげで、 エリック

+0

FKの値が変更されなくても、更新によってFKルックアップが発生しますか? –

+0

自分自身にカラムを設定してもそれはできないだろうと思いますが、わかりません。確認して、あなたに連絡しましょう。 – Anon246

+1

同じ値に更新してもルックアップが発生します。そのため、FKが他のテーブルを指しているテーブルで大量の更新を行うと、スキャンが行われたり、他のテーブルを検索したりする可能性があります。 (あなたのPK/FKコンボのすべてが索引付けされていることを確認する良い理由もあります)。 – Anon246

0

.1 p.2と混在して、つまり、変更された列のみを更新するパラメータ化されたUPDATE文を動的に構築します。これは、読み取り/書き込み速度が「読み取り」側にあり、更新をあまり頻繁に行っていない場合に機能し、(物理的な)更新パフォーマンスのためにクエリプランキャッシュを安全に交換できます。

関連する問題