MySQLデータベーストランザクションの仕組み【まとめ】

ここ数日、私はインタビューでデータベース トランザクション メカニズム、分離レベル、楽観的ロックと悲観的ロックについて何度も質問されました。以前はこれらについてある程度理解していたとしか言えませんでした。いくつかの概念はまだ段階にあります。記憶レベルが低くて理解できなかったので、「よくありません」と答えました。後から勉強のために本を読んでわかったことがいくつかあったので、ここに記録しておきます。

トランザクションとは何ですか?

トランザクションについて私が理解しているのは、完全なビジネス動作です。ビジネス動作には複数のアクションが含まれる場合があります。この完全なアクションがトランザクションを構成します。より典型的な例は銀行振込です。アカウント A をアカウント B に送金するには、アカウント A からの減算とアカウント B への追加という 2 つのアクションが必要です。これらのアクションが両方とも実行されるか、どちらも実行されないことを確認する必要があります。

トランザクションには、次のような ACID 特性があります。

# アトミック性 (原子性): アトミシティとは、トランザクションが分割不可能で、すべて成功またはすべて失敗、部分的に成功せず、部分的に失敗したことを意味します。途中で失敗した場合は、戦場をクリーンアップする必要があります。つまり、データはロールバックされます。

# 一貫性: 一貫性とは、トランザクションの最終結果を指し、データに異常がないことを保証します。一貫性は結果を重視し、原子性に基づいています。つまり、原子性が保証されれば、一貫した結果が得られます。

# 分離: 分離とは、トランザクションが送信されるまでは他のトランザクションから見えず、トランザクション間のデータが分離されていることを意味します (もちろん、分離の程度はレベルによって異なります)。

# 耐久性: トランザクションは送信された後は永続的になり、長期間保存できます。

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

トランザクションの分離レベルを理解する前に、データ読み取りのいくつかの概念を理解する必要があります。

● ダーティ リーディング: 他の人がまだ送信していないデータを読み取ることを意味します。

# 反復読み取り: 同じもの内の 2 つのクエリです。他の人がクエリ内のレコードを変更して送信すると、2 番目のクエリには表示されず、同じレコードは表示されません。 2 つのクエリが矛盾しています。

# ファントム リーディング: 1 つのものの中に 2 つのクエリが含まれています。他の人がレコードを追加して送信すると、2 番目のクエリで見つかる内容は最初のレコードと一致しません。

トランザクション制御は多くのレベルに分かれています。レベルは分離の程度を決定します。MySQL には 4 つのレベルがあります:

● コミットされていない読み取り: このレベルは最下位レベルでは、トランザクション A の変更がコミットされていない場合、トランザクション B にそれが表示され、データのダーティ リードが発生します。このタイプは通常は使用されません。

# 送信された読み取り: 物 A の変更は、送信された後でのみ B に表示されます。この場合、データのファントム読み取りの問題が発生し、2 つのクエリの結果は異なります。

# 反復読み取り: MySQL のデフォルト レベルです。このレベルの 2 つのクエリの間で、特定のレコードが途中で変更され、他のトランザクションからは見えなくなり、クエリの反復が保証されます。同じレコードは一貫しています。ただし、他のトランザクションは新しい追加に対して表示されるため、新しいファントム読み取りは引き続き発生します。

## ● シリアル化可能: トランザクションはシリアルに実行され、クエリされた各レコードはロックされます。ブロッキングが発生し、同時実行により重大なパフォーマンスの問題が発生するため、通常、このタイプは使用されません。

#分離レベルの概要チャート

トランザクションの分離実装

トランザクション内分離の制御には、時間を区切って分離を実現するロック方式と、複数のバージョンを記録して分離を実現するバージョン管理方式があります。

1. ロック

MySQL のロックは読み取りロックと書き込みロックに分かれており、読み取りロックはデータを読み取るためのものであるため、複数の人が同じデータを読み取ることができます。書き込みロックはデータ変更を伴うため、他の書き込みロックや読み取りロックと競合し、排他的な性質を持っています。

ロックの細分性の点では、テーブル レベルのロックと行レベルのロックに分けられます。テーブル ロックは通常、テーブル構造が変更されるかテーブル全体が更新されるときに発生し、すべての読み取りと書き込みがブロックされます。このテーブルに対する操作。行レベルのロックは通常、指定されたレコードが更新されるときに発生し、指定されたレコードのみがロックされます。ロックの粒度が小さいほど、同時実行性が高くなります。行レベルのロックが優先され、テーブル ロックは可能な限り回避される必要があります。これは、プログラムのロックの粒度と同じ原理です。

2. マルチバージョン同時実行制御

パフォーマンス上の理由から、MySQL には行レベルのロックのほかに、ストレージによって制御されるマルチバージョン同時実行制御という別の方法があります。エンジンの実装。

この本では、InnoDB の簡単な実装方法を説明しています。この方法では、複数のバージョンを持つ 1 つのレコードを使用します。各レコードに 2 つの非表示の列が追加されます。1 つは作成バージョン番号、もう 1 つはバージョン番号の削除です。トランザクションがオープンされるたびに、トランザクションのバージョン番号が割り当てられ、トランザクションのバージョン番号がインクリメントされ、トランザクション内の操作がこのバージョン番号に基づいて比較されます。詳細は次のとおりです:

# クエリ時: 現在のトランザクションの前に存在し、このトランザクションによって作成され、削除されていないレコードをクエリします。つまり、create version number 現在のバージョン番号)

#● 挿入時: 記録された作成バージョン番号は、現在のトランザクションのバージョン番号です。

# 削除時: 削除された更新レコードのバージョン番号が現在のトランザクションのバージョン番号となります。

# 更新時: 新しいレコードを挿入します。作成バージョン番号は現在のトランザクション バージョン番号です。元のレコードの削除バージョン番号は、削除されたことを意味する現在のトランザクション バージョン番号に変更します。実際、ここでの更新は、別のレコードを削除して追加することと同じです。

3. 楽観的ロックと悲観的ロック

ロックは利用の観点から悲観的ロックと楽観的ロックに分けられます。 I 見つかったデータは他の人によって変更されている可能性があるため、クエリを実行するときに、このデータのバッチは他の人が操作できないようにロックされます。オプティミスティック ロックは非常に楽観的な態度を持ち、見つかったデータが変更されることは基本的に不可能であると考えられます。クエリ時にこのデータのバッチがロックされないように変更し、変更が送信されるときに、他の人によって変更されているかどうかを確認します。手遅れになる前に埋め合わせても遅くありません。

楽観的ロックと悲観的ロックの実装:

# 悲観的ロックは、クエリ時に更新に select... を使用することで、データベース レベルで簡単に解決できます。データのこの部分をロックします。

# 楽観的ロックの実装は悲観的ロックよりも複雑です。データベースにバージョン番号の列を置くことができます。更新するときは、バージョン番号をすべて 1 にして、見つけたデータが変更されたかどうかを確認します。変更されたものは更新されないか、プログラムが例外をスローします。

オプティミスティック ロックとペシミスティック ロックのどちらを使用するべきですか:

パフォーマンスの観点からオプテ​​ィミスティック ロックの方がパフォーマンスが良いことを考慮すると、クエリと更新の間にロック操作はありませんが、実装可能 悲観的ロックほど単純ではないため、失敗する可能性があります。では、考慮すべき要素は、システムの同時実行性が高いかどうかです。衝突の確率はどれくらいですか?同時実行性が高い場合は、楽観的ロックを使用することをお勧めします。それ以外の場合は、悲観的ロックのような単純な方法を使用することをお勧めします。

推奨される mysql ビデオ チュートリアル、アドレス:

//m.sbmmt.com/course/list/51.html

以上がMySQLデータベーストランザクションの仕組み【まとめ】の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。