トランザクションはデータベース操作の基礎であり、データの整合性と安定性を保証します。MySQLにおけるトランザクション管理は、特に分離レベルとロックのメカニズムに依存しています。この記事では、MySQLのトランザクション分離レベルについて詳しく解説し、それぞれのレベルでどのようなロックが働くかを説明します。
もちたトランザクションはデータベースと付き合っていく上で、必ず理解しないといけないところです！理解しないとデータの不整合が起きて大変なことになってしまいます。。。この記事で少しでも理解してくれたら嬉しいです！
トランザクション分離レベルとその問題について
MySQLでは、以下の4つのトランザクション分離レベルが提供されています。
| 分離レベル | ダーティーリード | ノンリピータブルリード | ファントムリード | パフォーマンス | デフォルト設定 |
| READ UNCOMMITTED | |||||
| READ COMMITTED | – | PostgreSQL | |||
| REPEATABLE READ | – | – | MySQL | ||
| SERIALIZABLE | – | – | – |
- READ UNCOMMITTED: このレベルでは、他のトランザクションによって変更されたがまだコミットされていないデータを読み取ることができます。これは「ダーティリード」と呼ばれ、データの一貫性に重大な問題を引き起こす可能性がありますが、最も低い隔離レベルであり、ロックの必要が最も少ないため、パフォーマンスは最も高いです。
- READ COMMITTED: コミットされたデータのみを読み取ることができます。これにより、ダーティリードは防ぐことができますが、同じトランザクション内で同じデータを複数回読み取ると、異なる結果が返される「ノンリピータブルリード」は発生する可能性があります。
- REPEATABLE READ: このレベルでは、トランザクション開始時のデータの状態を保持し、トランザクションが終了するまでその状態を維持します。これにより、ノンリピータブルリードは防げますが、異なるトランザクションによって新しい行が追加されると、そのデータが「ファントムリード」として出現することがあります。
- SERIALIZABLE: 最も厳格な分離レベルで、トランザクションは順序どおりに逐次実行されるかのように扱われますが、パフォーマンスがかなり悪くなります。
ダーティーリード
ダーティーリードは、あるトランザクションが、他のトランザクションによって変更されたがまだコミットされていないデータを読み取ることができる状況を指します。これは、先行するトランザクションが失敗してロールバックされた場合、後続のトランザクションがコミットされていない不正確または無効なデータに基づいて操作を行う可能性があるため問題となります。
例： トランザクションAがアカウントの残高を更新するが、まだコミットしていない。トランザクションBがその同じアカウントの残高を読み取ると、更新されたがまだ確定していない残高を見ることができる。もしトランザクションAが失敗して変更をロールバックした場合、トランザクションBは無効なデータを読み取ったことになります。
ノンリピータブルリード
ノンリピータブルリードは、同じトランザクション内で同じデータを複数回読み取った際に、異なる結果が返される状況を指します。これは、最初の読み取り後に別のトランザクションがそのデータを変更し、コミットする場合に発生します。
例： トランザクションAがあるレコードを読み取る。その後、トランザクションBがそのレコードを変更し、コミットする。トランザクションAが再度同じレコードを読み取ると、異なるデータが返される。
ファントムリード
ファントムリードは、同じトランザクション内で一連のレコード（たとえば、特定の条件に一致するレコード）を複数回クエリする場合に、異なる行が見える現象です。これは、最初のクエリ実行後に別のトランザクションが新しいレコードを挿入し、コミットする場合に発生します。
例： トランザクションAが特定の条件に一致するレコードのセットをクエリする。その後、トランザクションBが新しいレコードを挿入し、そのレコードがトランザクションAの元のクエリ条件に一致する。トランザクションAが再度クエリを実行すると、新しいレコード（ファントム）が含まれることになります。
これらの分離レベルは、トランザクションが他の同時実行トランザクションからどの程度「隔離」されるかを定義します。レベルが高いほど、より厳格なデータ整合性が保証されますが、パフォーマンスへの影響も大きくなります。
ロックのメカニズム
MySQLのトランザクションでは、主に以下の二種類のロックが使用されます。
- 共有ロック（Shared Lock）: 他のトランザクションが読み取りを行うことを許可しながら、書き込みを防ぎます。
- 排他ロック（Exclusive Lock）: 他のトランザクションが読み取りまたは書き込みを行うことを防ぎます。
加えて、MySQLでは「ギャップロック（Gap Lock）」や「ネクストキーロック（Next-Key Lock）」といった、範囲に対するロックもサポートしており、これらは特にREPEATABLE READやSERIALIZABLEレベルで重要になります。
これらはトランザクションの安全性を高める一方で、適切に使用しないとデッドロックを引き起こす原因となります。
もちたギャップロックでデッドロックがかかっている場合は気づきにくいから注意してください！！
デッドロックについて
デッドロックは、複数のトランザクションが相互にリソースの解放を待っている状態で、どのトランザクションも進行できなくなる現象です。例えば、トランザクションAがリソース1をロックし、トランザクションBがリソース2をロックし、それぞれが相手が持つリソースの解放を待っている場合、デッドロックが発生しています。
デッドロックの対処法
- タイムアウト: MySQLはデッドロックを検出し、タイムアウトに達したトランザクションを自動的にロールバックします。
- ロック順序の統一: すべてのトランザクションでリソースへのアクセス順序を統一することで、デッドロックの可能性を減少させます。
- トランザクションの分割: 大きなトランザクションをより小さな単位に分割することで、ロックするリソースの数と期間を減らし、デッドロックのリスクを低減します。
- リトライポリシーの実装: デッドロックによるロールバックが発生した場合、アプリケーションでトランザクションを自動的に再試行する。
まとめ
MySQLのトランザクション分離レベルとロックのメカニズムを適切に理解し、使い分けることで、データベースの整合性を保ちつつ、アプリケーションのパフォーマンスを最適化することができます。重複データの挿入やデータの不整合を避けるためには、アプリケーションの要件に応じて正しい分離レベルとロック戦略を選択することが重要です。
