頻繁に呼び出される更新SPの分離レベルを修正しますか？

Question

株価を追跡する単一のテーブルがあるとします（この問題の簡単な例です）。私は1000ティッカーを追跡し、常に市場データを受け取り、ストアドプロシージャを介してテーブルを更新するプロセスを持っています。

私は、同じティッカーで発生した更新の衝突について心配していません。どんな理由であれ、同じティッカーの2つのアップデートがうまく適用されないと仮定しましょう（これは私のシナリオでは起こりません）。私は、ストアドプロシージャができるだけ少ない競合を持つようにしたいと思います。

現在のシナリオでは、procは同時に多くの時間が呼び出されており、タイムアウトしています。

現在、procは分離レベルとしてREPEATABLE READを使用しています。私はprocを書いていないので、なぜこれが選ばれたのか分からない。

私の質問は：

1. それはREPEATABLE READを使用して（間接的に）である可能性が、それはこれらのタイムアウトの原因？
2. 上記の基準に基づいてより適切な選択をするのがよいでしょうか？

Answer 1

分離レベルが増加すると、並行性が低下します。分離が高ければ高いほど、並行性は低くなります。 REPEATABLE READやSERIALIZABLEのような高い並行性レベルを使用すると、競合、ブロック、および並行性が低下します。

SNAPSHOTを除く。スナップショット、別名。行のバージョン管理は異なります。スナップショットONでは、読者はライターの背後で決してブロックされません。これは通常、集中的に読み込まれ、同時に書き込まれるワークロードには非常によくマッチします。これは、最初の有効なコストを持っていますが、私は強くSNAPSHOTのパフォーマンスを調査することによって開始することができ促すでしょう：分離レベルがなければならないこと

• Understanding Row Versioning-Based Isolation Levels
• Row Versioning Resource Usage
• Enabling Row Versioning-Based Isolation Levels

注意をあなたの読者によっても設定されます。