外部キー、ブロック、および更新の競合

今回は、子レコード挿入の実行プランが少し異なります。

すべてが以前と同じです（非表示のREADCOMMITTEDLOCKを含む） ヒント）例外 外部キーチェックで非クラスター化が使用されるようになりました 親テーブルの主キーを適用する一意のインデックス。最初のテストでは、このインデックスはクラスター化されました。

では、なぜ今回はブロックされないのですか？

2番目のセッションでのまだコミットされていない親テーブルの更新には排他的ロックがあります クラスター化されたインデックス ベーステーブルが変更されているため、行。 ParentValueへの変更 列はありません ParentIDの非クラスター化主キーに影響を与える 、非クラスター化インデックスの行がロックされないようにする 。

したがって、外部キーチェックは、競合することなく、非クラスター化主キーインデックスで必要な共有ロックを取得でき、子テーブルの挿入はすぐに成功します 。

プライマリがクラスター化された場合、外部キーチェックには、更新ステートメントによって排他的にロックされた同じリソース（クラスター化インデックス行）に対する共有ロックが必要でした。

動作は驚くべきものかもしれませんが、バグではありません 。外部キーチェックに独自の最適化されたアクセス方法を与えることで、論理的に不要なロックの競合を回避できます。 ParentIDであるため、外部キールックアップをブロックする必要はありません。 属性は同時更新の影響を受けません。

2。回避可能な更新の競合

以前のテストをスナップショットアイソレーション（SI）レベルで実行した場合、結果は同じになります。子行はブロックを挿入します 参照されたキーがクラスター化されたインデックスによって強制された場合 、ブロックしない キーエンフォースメントが非クラスター化を使用する場合 一意のインデックス。

ただし、SIを使用する場合の重要な潜在的な違いが1つあります。読み取りコミット（ロックまたはRCSI）分離では、子行の挿入は最終的に成功します 2番目のセッションでの更新がコミットまたはロールバックした後。 SIを使用すると、トランザクションが中止されるリスクがあります。 明らかな更新の競合が原因です。

スナップショットトランザクションはBEGIN TRANSACTIONで始まらないため、これを示すのは少し難しいです。 ステートメント—その時点以降の最初のユーザーデータアクセスから始まります。

次のスクリプトは、スナップショットトランザクションが実際に開始されたことを確認するためにのみ使用される追加のダミーテーブルを使用して、SIデモンストレーションを設定します。参照される主キーが一意のクラスター化を使用して適用されるテストバリエーションを使用します インデックス（デフォルト）：

ALTER DATABASE CURRENT SET ALLOW_SNAPSHOT_ISOLATION ON;
GO
DROP TABLE IF EXISTS
    dbo.Dummy, dbo.Child, dbo.Parent;
GO
CREATE TABLE dbo.Dummy
(
    x integer NULL
);
 
CREATE TABLE dbo.Parent
(
    ParentID integer NOT NULL,
    ParentNaturalKey varchar(10) NOT NULL,
    ParentValue integer NOT NULL,
 
    CONSTRAINT [PK dbo.Parent ParentID]
        PRIMARY KEY (ParentID),
 
    CONSTRAINT [AK dbo.Parent ParentNaturalKey]
        UNIQUE (ParentNaturalKey)
);
 
CREATE TABLE dbo.Child 
(
    ChildID integer NOT NULL,
    ChildNaturalKey varchar(10) NOT NULL,
    ChildValue integer NOT NULL,
    ParentID integer NULL,
 
    CONSTRAINT [PK dbo.Child ChildID]
        PRIMARY KEY (ChildID),
 
    CONSTRAINT [AK dbo.Child ChildNaturalKey]
        UNIQUE (ChildNaturalKey),
 
    CONSTRAINT [FK dbo.Child to dbo.Parent]
        FOREIGN KEY (ParentID)
            REFERENCES dbo.Parent (ParentID)
);

親行の挿入：

DECLARE
    @ParentID integer = 1,
    @ParentNaturalKey varchar(10) = 'PNK1',
    @ParentValue integer = 100;
 
INSERT dbo.Parent 
(
    ParentID, 
    ParentNaturalKey, 
    ParentValue
) 
VALUES 
(
    @ParentID, 
    @ParentNaturalKey, 
    @ParentValue
);

まだ最初のセッション 、スナップショットトランザクションを開始します：

-- Session 1
SET TRANSACTION ISOLATION LEVEL SNAPSHOT;
BEGIN TRANSACTION;
 
-- Ensure snapshot transaction is started
SELECT COUNT_BIG(*) FROM dbo.Dummy AS D;

2番目のセッション （任意の分離レベルで実行）：

-- Session 2
DECLARE
    @ParentID integer = 1,
    @ParentNaturalKey varchar(10) = 'PNK1',
    @ParentValue integer = 200;
 
BEGIN TRANSACTION;
    UPDATE dbo.Parent 
    SET ParentValue = @ParentValue 
    WHERE ParentID = @ParentID;

最初のセッションで子行を挿入しようとしていますブロック 予想通り：

-- Session 1
DECLARE
    @ChildID integer = 101,
    @ChildNaturalKey varchar(10) = 'CNK1',
    @ChildValue integer = 999,
    @ParentID integer = 1;
 
INSERT dbo.Child 
(
    ChildID, 
    ChildNaturalKey,
    ChildValue, 
    ParentID
) 
VALUES 
(
    @ChildID, 
    @ChildNaturalKey,
    @ChildValue, 
    @ParentID    
);

違いは、トランザクションを終了したときに発生します 2番目のセッションで。 ロールバックした場合 、最初のセッションの子行の挿入は正常に完了します 。

代わりにコミットする場合 オープントランザクション：

-- Session 2
COMMIT TRANSACTION;

最初のセッションで、更新の競合が報告されます そしてロールバックします：

CREATE TABLE dbo.Parent
(
    ParentID integer NOT NULL UNIQUE CLUSTERED
);
 
-- Shorthand (implicit) syntax
-- Fails with error 1773
CREATE TABLE dbo.Child
(
    ChildID integer NOT NULL PRIMARY KEY NONCLUSTERED,
    ParentID integer NOT NULL 
        REFERENCES dbo.Parent
);
 
-- Explicit syntax succeeds
CREATE TABLE dbo.Child
(
    ChildID integer NOT NULL PRIMARY KEY NONCLUSTERED,
    ParentID integer NOT NULL 
        REFERENCES dbo.Parent (ParentID)
);