13

SQL Server 2008ではV、テーブルのビューがAありB、おおよそ次のようになります

create view V as
    select * from A
    union all
    select * from B

から読み取るVと、クエリはベース テーブルに対してインテント共有ロックを取得しますが、ビュー オブジェクト自体に対してもインテント共有ロックを取得します。

テーブルに IS ロックが必要な理由は明らかであり、ビューの IS ロックにより、ビューの基礎となるテーブルへの同時変更が防止されることがわかります。それはいいです。

クエリ プランには、ビューについての言及は含まれていません。これは完全にコンパイルされており、この場合の結果のプランは、2 つのベース テーブルの行を単純に連結したものです。実際、クエリ プラン XML でビューについて言及されているのは、ステートメント テキストだけです。

テーブルに2 番目のビューを追加するとU、 からの読み取りVによってロックがかかることはありませんU。Aこれは、エンジンがとのすべてのビューで IS ロックを取得することを除外しますB。

データベース エンジンは、ビューをロックすることをどのように認識していますか?

  • ステートメント テキストは再度解析されますか?
  • この情報を渡すために、クエリプランナーと基になる実行の間に他の情報チャネルはありますか?

詳細については、対応する質問をdba.stackexchange参照してください。

4

3 に答える 3

4

dba.stackexchange に関する私の回答からのコピー:

エンジンまたはオプティマイザー関連の究極の情報源である Conor Cunningham から:

コンパイル中に物事を追跡して、実行時にチェックします。この目的のために、実行時に物事を解析しません。

注: あるリリースから別のリリースまでの内部動作は保証されていません。これは、公式にサポートされている表面積の下にあります。

私の考えでは、実行計画のバイナリ バージョン (XML を介して読み取り可能で公開されているものではなく、バイナリ バージョンのサブセットにすぎません) には、元のクエリで参照されているビューへのポインターが含まれている必要があります。テキスト（これは上でほのめかされました）。明らかに、毎回クエリ テキストを解析しているわけではありません。Conor は上記のことを暗示していますが、これがどこにどのように保存されているかについての詳細を明かさないように注意しています。彼はおそらく、探偵の仕事を奨励したくない. :-)

于 2012-04-25T15:01:35.227 に答える
2

sys.dm_exec_query_optimizer_infoSQL Serverクエリオプティマイザーの詳細を返すビューを見ると、返される詳細の1つは次のフィールドです。

ビュー参照-クエリでビューが参照された回数。

ビューが参照される回数は、おそらく実行プランの一部として、どこかで追跡されているように見えます...ビューが展開されても、実行プランには、で使用されたビューの詳細が含まれていると思います。クエリを実行し、ISこれらの参照ビューに対して適切なロックを発行します。

于 2012-04-23T19:24:24.333 に答える
0

デフォルトでは、ビューはマクロのように、それらを参照するクエリに展開されます。

これはオフにすることも、具体化されている場合は変更することもできますが、マクロのようなインライン展開が標準です。これは、ロックなどが次のように動作することを意味します...

SELECT
  *
FROM
  blah
INNER JOIN
(
  yourViewCode
)
  AS aView
    ON aView.id = blh.id
于 2012-04-23T17:42:57.760 に答える