MySQL ファントムリードとその排除方法の詳細な説明

これは、データベース分離レベルに関するポピュラーサイエンスの記事です。データベースにおける有名なファントムリード現象を理解することを目的としています。トピックに焦点を当てるため、ダーティリードと非反復リードについては説明しません。

トランザクション分離レベル

MySQL には 4 つのトランザクション分離レベルがあります。

読み取り非コミット: ダーティリード、非反復読み取り、およびファントムリードの問題が存在します。読み取りコミット: ダーティリードはありませんが、非反復読み取りとファントムリードの問題が存在します。反復読み取り: ダーティリード、非反復読み取りの問題はありませんが、ファントムリードの問題が存在します。シリアル化: ダーティリード、非反復読み取り、およびファントムリードの問題を解決しますが、実行は完全にシリアルであり、パフォーマンスは最も低くなります。

ファントムリーディングとは何ですか?

ファントムリードに関する誤った理解: ファントムリードとは、トランザクション A が 2 つの選択操作を実行して異なるデータセットを取得することを意味します。つまり、選択 1 では 10 個のレコードが取得され、選択 2 では 11 個のレコードが取得されます。これは実際にはファントムリードではなく、非反復読み取りの一種であり、RU RC レベルでのみ発生し、MySQL のデフォルトの RR 分離レベルでは発生しません。

ファントムリーディングについての私の理解は次のとおりです。

ファントムリードは、トランザクション内の複数の読み取りから取得された結果セットが異なることを意味するものではありません。ファントムリードに関してより重要なのは、特定の選択操作から取得された結果セットによって表されるデータ状態が、後続のビジネス操作をサポートできないことです。具体的には、選択したレコードが存在せず、このレコードを挿入しようとしているが、挿入を実行すると、このレコードがすでに存在し、挿入できないことがわかり、まるで錯覚のようだ。

例を挙げると理解しやすくなるかもしれません:

mysql> テーブル user\G の作成を表示します
************************** 1. 行 ****************************
 テーブル: ユーザー
テーブルの作成: CREATE TABLE `user` (
 `id` int(11) NULLではない、
 `name` varchar(32) デフォルト NULL,
 主キー (`id`)
) エンジン=InnoDB デフォルト文字セット=utf8

2 つのトランザクション T1 と T2 をそれぞれ開始し、分離レベルを Reaptable-Read に設定します。

T1:

mysql> グローバルトランザクション分離レベルを繰り返し読み取りに設定します。      

mysql> 開始します。
mysql> ユーザーから * を選択します。
mysql> ユーザー値に挿入（1、 'jeff'）;
エラー 1062 (23000): キー 'PRIMARY' のエントリ '1' が重複しています

mysql> ユーザーから * を選択します。

T2:

mysql> グローバルトランザクション分離レベルを繰り返し読み取りに設定します。      

mysql> 開始します。
mysql> ユーザー値に挿入（1、 'jeff'）;
mysql> コミット;

T1 トランザクションは、テーブル内に ID 1 のレコードがあるかどうかを確認し、ない場合はそれを挿入します。

T2 は干渉レコードを挿入し、T1 でファントムリードが発生します。

上記の例では、トランザクション T2 を実行する前にトランザクション T1 が実行されるようにする必要があります。

上記の例では、T1 で読み取られたデータ状態が後続のアクションと意味的に矛盾しているため、T1 でファントムリードが発生します。クエリを実行すると、レコードが存在しないことが明確に示されますが、挿入を実行すると、主キーが重複していることが示されます。これはファントムの出現に似ているため、ファントムリードと呼ばれます。

ファントムリードを排除する方法

MySQL には現在、ファントムリードを取り除く 2 つの方法があります。

1. 選択操作 (SELECT ... FOR UPDATE) に行 X ロックを手動で追加します。その理由は、InnoDB の行ロックがインデックスをロックするためです。現在のレコードが存在しない場合でも、現在のトランザクションはレコードロックを取得します (レコードが存在する場合は行 X ロックが追加され、存在しない場合は次のキーロックギャップ X ロックが追加されます)。このようにして、他のトランザクションはこのインデックスのレコードを挿入できず、ファントムリードが排除されます。
2. 分離レベルをさらにSERIALIZABLEに上げる
効果をテストする

mysql> 開始します。

mysql> id = 2 の場合、user から * を選択して更新します。
mysql> ユーザー値に挿入（2、 'tony'）;

mysql> コミット;

T2:

mysql> 開始します。

mysql> ユーザー値に挿入（2、 'jimmy'）;
エラー 1062 (23000): キー 'PRIMARY' のエントリ '2' が重複しています

ここで、T1 が更新のためにクエリされると、インデックスは Innodb でロックされます (現在存在しない場合でも)。そのため、トランザクション T2 の挿入は、T1 がコミットされるまでブロックされます。このようにして、T1 は成功します。T1 の場合、ファントムリードは確かに排除されますが、T2 の挿入では重複した主キーが報告されますが、これも予想どおりです。

分離レベルを向上させてファントムリードを排除する別の方法については、興味のある方は自分で試してみてください。ここでは繰り返しません。システムが手動ロックを置き換える点を除けば、本質は同様です。

要約する

RR は、MySQL トランザクションのデフォルトの分離レベルです。これは、トランザクションのセキュリティとパフォーマンスの間の妥協点です。ファントムリードについて正しく理解した後、開発者は必要に応じてファントムリードを防止するかどうかを決定できます。

SERIALIZABLE は悲観的であり、ファントムリードが常に発生すると想定しているため、トランザクションに必要なリソースに自動的かつ暗黙的に排他ロックを追加します。このリソースにアクセスする他のトランザクションはブロックされ、待機状態になります。トランザクションは安全ですが、パフォーマンスを慎重に考慮する必要があります。

InnoDB ロックはインデックス用なので注意が必要です。行レコードをロックします。存在する場合は、X ロックを追加します。そうでない場合は、次のキーロック/ギャップロック/ギャップロックを追加します。これにより、InnoDB は、トランザクションによる特定のレコードの事前占有を実現できます。トランザクションが存在する限り、他のトランザクションはそれを占有できません。ロックについては後ほど特別記事で取り上げます。

以上がMySQLファントムリードとその解消方法の詳細な説明です。MySQLファントムリードとその解消方法の詳細については、123WORDPRESS.COMの他の関連記事をご覧ください。

以下もご興味があるかもしれません: