MySQLのトランザクション分離レベルについて

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

参考

トランザクション分離レベルについてのまとめ

ダーティリード、リピータブルリード、ファントムリードをちゃんと理解してからトランザクション分離レベルを理解しよう

トランザクション分離レベルは何のために存在するのか？

以下の複数トランザクション間で発生しうるReadに関する動作を許容/防ぐために存在する

ダーティーリード

コミットしてないデータが他のトランザクションから見える

e.g.

トランザクションAでデータを更新 (未コミット)

トランザクションBからトランザクションAで更新した未コミットのデータがセSelectできる

ファジーリード/ノンリピータブルリード

他トランザクションが対象レコードを更新(Update)してcommitしたとき、更新後のデータが見える現象

ノンリピータブルって意味がピンときてなかったんだけど、繰り返しselectしたときに同じ結果が取れないということかな

逆に繰り返し同じselectしたときに同じ結果が見れるのはリピータブル

e.g.

トランザクションAでデータをUpdateしコミット

トランザクションBでUpdateしたデータをSelectできる

MySQLの場合RepeatableReadのトランザクション分離レベルでも、SELECT ...FOR SHAREやSELECT...FOR UPDATEのようなロックを取得して参照を行う場合、ファジーリードが発生する場合がある。

ここで補足が必要なのが、分離レベルがREPEATABLEREADの場合に、「反復不能読み取り」と「ファントムリード」は「発生し得る」とされている点です。前述した表1のREPEATABLEREADの説明で「基本的にはほかのトランザクションにより変更されることはありません」としたのも、この点が理由です。REPEATABLEREADでの発生有無に関しては次のとおりです。

・LockingReadの場合：発生する

・それ以外の場合：発生しない

ファントムリード

他トランザクションが対象レコードを追加(Insert)または削除(Delete)してcommitしたとき、追加/削除後のデータが見える現象

おそらくおばけのように突然現れたり消えたりするイメージからファントムという名前がついているのだと思う

e.g.

トランザクションAでデータをInsert / Deleteしコミット

トランザクションBでInsertしたデータをSelectできるまたは、DeleteしたデータがSelectできなくなる

トランザクション分離レベルと各現象の発生有無

AWS Auroraの場合、デフォルトは以下の設定になってる

Writer: Read-Comiited

Reader: Repeatable-Read

Aurora MySQL の Aurora レプリカは常に、InnoDB テーブル上のオペレーションに、デフォルトのトランザクション分離レベル REPEATABLE READ を使用します。