MVCC とは何ですか?またギャップ ロックが設計される理由は何ですか?

この記事では、MVCC を理解し、設計の観点から MVCC と絶縁レベルの関係を紹介し、MVCC が設計される理由、RC と RR の絶縁レベルの違いについて説明します。

MVCC の役割

MVCC により、行ロックをサポートするほとんどのトランザクション エンジンは、単にデータベースの同時実行制御に行ロックを使用しなくなります。 代わりに、データベースの行ロックは行のバージョン番号と組み合わされており、わずかなオーバーヘッドのみで非ロック読み取りを実現できます。 これにより、データベースの同時実行パフォーマンスが向上します。

MVCC は、ロックフリーの形式を使用して、読み取り/書き込みの競合の問題を解決します。ここでの読み取りはスナップショット読み取りを指します。 つまり、MVCC によって実装されたスナップショット読み取りです。 ！ ！

MVCC とは

マルチバージョン同時実行制御 (MVCC) は、読み取り/書き込みの競合を解決するロックフリーの同時実行制御です。

レコードの各行には、作成バージョン番号とロールバック ポインタという 2 つの非表示列があります。トランザクションが開始された後はトランザクション ID が存在します。複数の同時トランザクションが特定の行を同時に操作します。行に対する異なるトランザクションの更新操作により複数のバージョンが生成され、ロールバック ポインタを使用して UNDO ログ チェーンが形成されます。 MVCC のスナップショットの読み取りは、トランザクション ID と作成バージョン番号を通じて行われます。

MVCC と分離レベルの関係

MVCC は、読み取り/書き込みの問題を解決することです。また、さまざまな構成を通じて、トランザクション開始後のスナップショットの 反復不可能な読み取りの問題も解決できます。

• #Non-repeatable read: 同じトランザクションで読み取られた一部のデータが変更されたか、一部のレコードが削除されました。

• ファントム リーディング: トランザクションが同じクエリ条件に従って以前に取得したデータを再度読み取ると、他のトランザクションによってクエリ条件を満たす新しいデータが挿入されていたことがわかります。この現象は次のように呼ばれます。幻の読書。

RC と RR は両方とも MVCC を実装していますが、なぜ RR が RC の反復不可能な読み取りの問題を解決するのでしょうか?

RC に反復不可能な読み取りの問題があるのは、開発者が意図的に設定しているだけであると考えることができます (複数の分離レベルを設定し、ユーザーは状況に応じて設定できます)。元々データベースにデータが登録されているので、RCが読み込んでも問題ないのでしょうか？また、Oracle データベース自体の分離レベルは RC です。

READ-COMMITTED (コミットされた読み取り)

Read コミットされた RC。この分離レベルでは、SQL レベルで一貫した読み取りを実現できます。各 SQL ステートメントは新しい ReadView を生成します。これは、2 つのクエリの間に他のトランザクションが送信され、矛盾したデータが読み取られる可能性があることを意味します。

REPEATABLE-READ (反復可能な読み取り)

反復可能な読み取り RR、ReadView が初めて作成された後、この ReadView はトランザクションの終了まで維持されます。 , トランザクション実行中に可視性が変化しないため、トランザクション内で繰り返し読み取りが可能になります。

MVCC とギャップ ロック

MVCC ロックフリーは、読み取り/書き込み競合の問題を解決します。 そして、反復不可能な読み取りの問題を解決します。これにより、RC と RR の 2 つの絶縁レベルが実現されます。

そして

ギャップ ロック は依然として本質的にはロックであり、2 つの同時トランザクションの実行をブロックします。

それでは、なぜ RR がギャップ ロックに入るのですか? それは単にファントム リーディングの問題を解決するためですか?

注: ギャップ ロックは RR 分離レベルでのみ存在します。

ギャップ ロックはファントム読み取りの問題をある程度解決できますが、ギャップ ロックの導入は binlog のステートメント モードのバグに対処するためだと思います。

mysql データベースのマスター/スレーブ レプリケーションは binlog に依存します。 mysql5.0 より前では、binlog モードにはステートメント形式のみがありました。このモードの特徴は、binlog の記録順序がデータベーストランザクションのコミット順序であることです。

ギャップ ロックがない場合、次のシナリオが発生します: マスター ライブラリには 2 つのトランザクションがあります:

1. 最初のトランザクションdelete id<6, and then before commit;

2. Transaction b direct insert id=3, and complete the commit;
3. Transaction a commits;
この時点で binlog で記録されたログは次のとおりです。トランザクション b が最初に実行され、トランザクション a が実行されます (ビンログにコミット順序が記録されます)

このとき、マスター データベースのテーブルには id=3 のレコードがありますが、スレーブ データベースが最初に挿入し、スレーブデータベースには記録されません。

これにより、マスター データとスレーブ データの間で不整合が発生します。

このバグを解決するために、ギャップ ロックが RR レベルで導入されます。

[関連する推奨事項:

mysql ビデオ チュートリアル ]

以上がMVCC とは何ですか?またギャップ ロックが設計される理由は何ですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。