完全なテーブルが行ではなくロックされるのはなぜですか？

Question

私は、

create table temp 
(
    id int, 
    name varchar(10) 
) 
insert into temp values(1,'a'); 

をこのSQLを実行したが、その後私は、細かい

select 1 from temp where id = 1 

すべてを実行します。その後、私は

select 1 from temp where id = 1 

しかし、何も返されません。このとき、実行

それから私は、コミットされていない挿入を実行

SET NOCOUNT ON; 
    DECLARE @TranCount INT; 
    SET @TranCount = @@TRANCOUNT; 



     IF @TranCount = 0 
      BEGIN TRANSACTION 
     ELSE 
      SAVE TRANSACTION Insertorupdatedevicecatalog; 

insert into temp values(2,'b') 

。 2行目の代わりに完全なテーブルをロックするのはなぜですか？

Answer 1

SQL Serverはテーブル全体をロックしていません。私は、単一の行IDが書き込みトランザクションによってロックされていることがわかります。

索引がないため、読者は表全体をスキャンする必要があります。

これは、それが挿入された行上にXロックによってブロックされることを意味します。基本的には、読者は他のトランザクションがこの行を実際にコミットするかロールバックするかを決定するのを待ちます。

セッション51にid2が挿入されました。セッション54はブロックされたセレクトです。ここではページロックやテーブルロックはありません（ここで重要ではないインテントロックは別です）。

テーブルがヒープ（通常のような一意のCIはありません）であるという事実は、ここで予期しないロックを引き起こします。この問題は、ID上に一意のCIを作成することで解決します。

Answer 2

私の推測では、おそらくテーブル自体がロックされていない可能性があります。 SQL Serverは、新しい行を挿入する場所を知るために、挿入される値の周りの行の範囲をロックする必要があります（読み込みを禁止する書き込みロック）。テーブルには行がほとんどないので、テーブルがロックされているように見えます。より多くの行を追加すると、単一の行を挿入するときにこの動作が表示されません。

ところで、テーブルにはプライマリキーまたはクラスタ化インデックスが必要です。これにより、将来的に行を追加する際に役立ちます。それ以外の場合は、スキャンを実行することになります。これにより、更新（およびおそらく挿入）にかかる時間が長くなります。