SQLトランザクションは指定されたビューからのみローをロックできます

Question

マルチテナントアプリケーションでは、TenantIdカラムのテーブルがあります。このテーブルは、CONTEXT_INFOに格納されたTenantIdを使用して、単一のテナントに属する行を選択するビューを使用してのみアクセスされます。このビューが特定のテナント（つまり、同じTenantIdを持つ行のみをロックする）に対して返すトランザクションのみをトランザクションに持たせる方法はありますか？

挿入/更新/削除されるデータがTenantId列に異なる値を持つデータと決して衝突しないと確信したら、テーブル全体をロックするとパフォーマンスが低下します。

WHERE節を使用していくつかのテーブル行を制限する他のビューにも同じパターンが適用されます。

Answer 1

マルチテナント型の展開でTenantIdカラムはクラスタ化インデックスを含むすべての単一のインデックス、における左端の列でなければなりません。結論は、マルチテナントアプリケーションではヒープを持つことができないということです。

のクエリがの場合は、TenantId=@currentTenantIdという述語を追加する必要があるため、すべてのテーブルのテナントデータスライスの外側にクエリが追加されることはありません。これにより、2人のテナントの間に競合がないことが保証されます。なぜなら、各テナントはインデックスの部分だけに関心があるからです。

TenantIdでパーティション化を使用すると、何とか同様の解決策を達成できますが、パーティション化テーブルに固有の現在の1000パーティション制限とパフォーマンスの低下を考えれば、インデックスキーソリューションを強く推奨します。

ロックエスカレーション（明示的にはALTER TABLE SET LOCK_ESCALATIONで無効にすることができます）やバルクロードテーブルロック（sp_tabeloptionで無効）のような「状態」を破損するものがあります。

この知識で、あなたの質問を再訪し、「テナントが別のテナントが所有するリソースを決してロックできないように孤立化することはできますか？その答えは、適切なテナント固有のアクセスパスがの行セットにあることを確認する限り、はいです。これは、私が最初の段落で言うことを正確に変換します。すべてのインデックスに一番左のキーとして追加します。すべてのクラスタ化されたものを含み、ヒープはありません。小規模な印刷物であればその解決策はほとんどの場合有効ですが、テナントが別のテナントが所有するリソースをロックできる特定のシナリオが常に存在します。しかし、より良いアイソレーションを得るには、テナントごとに1つのdbを用意する必要があります。これは展開/保守/アップグレードの悪夢です。