MySQL トランザクションの詳細

原子性:
	すべて成功するか、すべて失敗するかのどちらかです。Undo ログは一貫性を実現します。
	たとえば、転送前と転送後の 2 つの金額の合計は変更されません。分離: データベースは、トランザクションが外部の同時操作の影響を受けない「独立した」環境で実行されるように、特定の分離メカニズムを提供します。ロック、MVCC マルチバージョン同時実行制御。耐久性: トランザクションの送信はディスクの再実行ログに保持されます。

ダーティ リード (ダーティ リード) トランザクションが別のトランザクションのコミットされていないデータにアクセスします。
	トランザクションがデータにアクセスしてデータを変更し、この変更がまだデータベースにコミットされていない場合、別のトランザクションもデータにアクセスしてデータを使用します。
非反復読み取り (トランザクションは同じクエリを 2 回実行しますが、異なるデータを取得します):
	トランザクションは、あるデータを読み取り、次に前に読み取ったデータを読み取ります。そのデータが、前に読み取ったデータと一致していないことが検出されます。ファントム リード (トランザクションが同じクエリを 2 回実行し、異なるデータを取得する) を更新および削除します。
	トランザクションは、同じクエリ条件に従って以前にクエリされたデータを再読み取りますが、他のトランザクションがそのクエリ条件を満たす新しいデータを挿入したことを検出します。

トランザクション分離レベルA、Bを設定する
	セッショントランザクション分離レベルをコミットされていない読み取りに設定します。
セッションA
トランザクションを開始します。トランザクションを開始します。
データを挿入します INSERT INTO `db_test`.`t_user`(`id`, `name`) VALUES (5, 'DuQi');
セッションB
別の接続は select * from t_user; をクエリします。
	+----+----------+
	| ID | 名前 |
	+----+----------+
	| 1 | 張三 |
	| 2 | リシ |
	| 3 | 王武 |
	| 4 | 老王 |
	| 5 | ドゥキ |
	+----+----------+
	このとき、接続Bは接続AのコミットされていないトランザクションのレコードIDを照会します。これは5です。
	
ここでは、セッションが別のトランザクションからコミットされていないデータを読み取ったことを確認します。

トランザクション分離レベルを変更します。セッション トランザクション分離レベルを読み取りコミットに設定します。
A はトランザクションを開始します。
更新 B がクエリ ステートメント MySQL [db_test]> select * from t_user; を実行することを確認します。
		+----+----------+
		| ID | 名前 |
		+----+----------+
		| 1 | 張三 |
		| 2 | リシ |
		| 3 | 王武 |
		| 4 | 老王 |
		| 5 | ドゥキ |
		+----+----------+
	A は更新ステートメント update t_user set name = 'duqi' where id = 5; を実行します。
	B はクエリ ステートメントの開始トランザクションを実行します。
		MySQL [db_test]> t_user から * を選択します。
		+----+----------+
		| ID | 名前 |
		+----+----------+
		| 1 | 張三 |
		| 2 | リシ |
		| 3 | 王武 |
		| 4 | 老王 |
		| 5 | ドゥキ |
		+----+----------+
	A はトランザクションコミットをコミットします。
	B はクエリ ステートメントを実行します (同じトランザクションの 2 つのクエリの結果は矛盾しています)
		MySQL [db_test]> t_user から * を選択します。
		+----+----------+
		| ID | 名前 |
		+----+----------+
		| 1 | 張三 |
		| 2 | リシ |
		| 3 | 王武 |
		| 4 | 老王 |
		| 5 | ドゥキ |
		+----+----------+
削除の確認を続けます。A がトランザクションを開始します。B がトランザクションを開始します。トランザクションを開始します。
	A は、id = 5 の t_user からレコードを削除します。
	トランザクション B クエリは正常で、削除されたレコードは MySQL [db_test]> select * from t_user; に残っています。
		+----+----------+
		| ID | 名前 |
		+----+----------+
		| 1 | 張三 |
		| 2 | リシ |
		| 3 | 王武 |
		| 4 | 老王 |
		| 5 | ドゥキ |
		+----+----------+
	コミット。
	B はクエリを続行し、同じトランザクションでの複数のクエリの結果が矛盾していることを発見します。MySQL [db_test]> select * from t_user;
		+----+----------+
		| ID | 名前 |
		+----+----------+
		| 1 | 張三 |
		| 2 | リシ |
		| 3 | 王武 |
		| 4 | 老王 |
		+----+----------+

A と B の挿入を確認します。トランザクションを開始します。トランザクションを開始します。
	A はレコードを挿入します INSERT INTO `db_test`.`t_user`(`id`, `name`) VALUES (5, 'DuQi');
	BはMySQLにクエリを実行します [db_test]> select * from t_user;
		+----+----------+
		| ID | 名前 |
		+----+----------+
		| 1 | 張三 |
		| 2 | リシ |
		| 3 | 王武 |
		| 4 | 老王 |
		+----+----------+	
	A はトランザクションコミットをコミットします。
	B クエリは、A によって送信されたトランザクションをクエリすることもできます。MySQL [db_test]> select * from t_user;
		+----+----------+
		| ID | 名前 |
		+----+----------+
		| 1 | 張三 |
		| 2 | リシ |
		| 3 | 王武 |
		| 4 | 老王 |
		| 5 | ドゥキ |
		+----+----------+

トランザクション分離レベルを変更します。セッション トランザクション分離レベルの繰り返し読み取りを設定します。
A と B がトランザクションを開始します。
Aはデータを挿入する	
	`db_test`.`t_user`(`id`, `name`) に VALUES (5, 'DuQi') を挿入します。
B MySQLクエリ [db_test]> select * from t_user;
	+----+----------+
	| ID | 名前 |
	+----+----------+
	| 1 | 張三 |
	| 2 | リシ |
	| 3 | 王武 |
	| 4 | 老王 |
	+----+----------+
A はトランザクションコミットをコミットします。
B トランザクションクエリ MySQL [db_test]> select * from t_user;
	+----+----------+
	| ID | 名前 |
	+----+----------+
	| 1 | 張三 |
	| 2 | リシ |
	| 3 | 王武 |
	| 4 | 老王 |
	| 5 | ドゥキ |
	+----+----------+
異なるトランザクション間で、挿入を照会できることがわかります。更新と削除の検証を続けましょう。A と B がトランザクションを開始します。A は更新します。update t_user set name = 'duqi' where id = 5;
	B MySQLクエリ [db_test]> select * from t_user;
		+----+----------+
		| ID | 名前 |
		+----+----------+
		| 1 | 張三 |
		| 2 | リシ |
		| 3 | 王武 |
		| 4 | 老王 |
		| 5 | ドゥキ |
		+----+----------+	
	Aはトランザクションをコミットする
	BはMySQLのクエリを続行します [db_test]> select * from t_user;
		+----+----------+
		| ID | 名前 |
		+----+----------+
		| 1 | 張三 |
		| 2 | リシ |
		| 3 | 王武 |
		| 4 | 老王 |
		| 5 | ドゥキ |
		+----+----------+
	削除の確認を続けましょう。A と B はトランザクションを開始します。トランザクション A は削除操作 delete from t_user where id = 5; を実行します。
		トランザクション B はクエリ MySQL [db_test]> select * from t_user; を実行します。
			+----+----------+
			| ID | 名前 |
			+----+----------+
			| 1 | 張三 |
			| 2 | リシ |
			| 3 | 王武 |
			| 4 | 老王 |
			| 5 | ドゥキ |
			+----+----------+
		A はトランザクションをコミットし、B は MySQL のクエリを続行します [db_test]> select * from t_user;
			+----+----------+
			| ID | 名前 |
			+----+----------+
			| 1 | 張三 |
			| 2 | リシ |
			| 3 | 王武 |
			| 4 | 老王 |
			| 5 | ドゥキ |
			+----+----------+
REPEATABLE-READ トランザクション分離レベルでは削除と更新の問題は解決されますが、挿入の問題は依然として存在します。

MySQL INNODB での mvcc の実装は、主にデータベースの同時パフォーマンスを向上させ、読み取り/書き込み競合をより適切に処理して、読み取り/書き込み競合が発生した場合でも、非ロックおよび非ブロッキングの同時読み取りを実現できるようにすることを目的としています。

共有モードでのロックの選択 (共有ロック)、更新の選択、更新、挿入、削除 (排他ロック) などの操作はすべて現在の読み取りです。
なぜ「Current Reading」という名前なのですか?
	つまり、レコードの最新バージョンを読み取ります。読み取り時には、他の同時トランザクションが現在のレコードを変更できないようにする必要があり、読み取られたレコードはロックされます。

たとえば、ロック解除された選択操作はスナップショット読み取りであり、ロックなしの非ブロッキング読み取りです。
スナップショット読み取りの前提は、分離レベルがシリアル レベルではないことです。シリアル レベルでのスナップショット読み取りは、現在の読み取りに退化します。
スナップショット読み取りの理由は、同時実行パフォーマンスを向上させるためです。スナップショット読み取りの実装は、マルチバージョン同時実行制御、つまり MVCC に基づいています。MVCC は行ロックのバリエーションと考えることができますが、多くの場合、ロック操作を回避し、オーバーヘッドを削減します。

MVCC マルチバージョン同時実行制御とは、読み取り操作と書き込み操作で競合が発生しないように、データの複数のバージョンを維持することを指します。スナップショット読み取りは、MVCC を実装するための MySQL の非ブロッキング読み取り機能です。
Mysql の mvcc モジュールの具体的な実装は、3 つの暗黙的なフィールド、undo ログ、および readview コンポーネントによって実装されます。

1. 読み取り-読み取り: 問題はなく、同時実行制御も必要ありません。2. 読み取り-書き込み: スレッドの安全性の問題があり、トランザクション分離レベルの問題が発生する可能性があり、ダーティ読み取り、反復不可能な読み取り、ファントム読み取りが発生する可能性があります。3. 書き込み-書き込み: スレッドの安全性の問題があり、更新の損失の問題が発生する可能性があります。

1. データベースの同時読み取りと書き込みを行う際に、読み取り操作中に書き込み操作をブロックすることなく実行でき、書き込み操作で読み取り操作をブロックする必要がないため、データベースの同時読み取りと書き込みのパフォーマンスが向上します。 2. ダーティ リード、ファントム リード、非反復読み取りなどのトランザクション分離の問題を解決しますが、更新損失の問題は解決できません。

DB_TRX_ID 最後に変更されたトランザクション ID:
	6バイト、このレコードを作成した、またはこのレコードを最後に変更したトランザクションIDを記録します。
DB_ROLL_PTR ロールバック ポインタ:
	7 バイト、このレコードの前のバージョンを指し、undolog と連携するために使用され、以前の古いバージョンを指す DB_ROW_ID 隠し主キー:
	6 バイト。データベース テーブルに主キーがない場合、InnoDB は自動的に 6 バイトの row_id を生成します。

挿入操作を実行する場合、生成される UNDO ログはトランザクションのロールバック時にのみ必要であり、トランザクションがコミットされた直後に破棄できます。更新および削除操作を実行する場合、生成される UNDO ログはトランザクションのロールバック時だけでなく、スナップショットの読み取り時にも必要となるため、気軽に削除することはできません。スナップショットの読み取りまたはトランザクションのロールバックにログが関係しない場合にのみ、対応するログはパージ スレッドによって均一にクリアされます (データが更新または削除されると、古いレコードのみが設定されます。レコードの delete_id が true で、DB_TRX_ID がパージ スレッドの読み取りビューに表示されている場合、このレコードは確実にクリアできます)

挿入操作を実行すると、対応する削除文が生成されます。削除操作を実行すると、元のデータの挿入文がバックアップされます。更新を実行すると、元のデータの更新文が記録されます。この操作は、レコードのロールバックに便利です。

読み取りビューの最大の機能は、トランザクションがスナップショットを実行している場合、レコードのために作成され、現在のトランザクションが読み取られる可能性があるか、最新のデータが読み取られている可能性があります変更するデータの最新のレコードでDB_TRX_IDを取り出し、DB_TRX_IDが読み取りビューの属性と比較され、DB_TRX_IDがDB_ROLL_LOLL_LOLL LOLL POINTRYを介して削除された場合、DB_TRX_IDが視認性の属性と比較された場合、DB_TROLLBACK POINERSを介して摂取されます。条件を満たすB_TRX_IDは、このDB_TRX_IDが配置されている古いレコードです。

trx_list:
	読み取りビューが生成された時点でシステム内でアクティブなトランザクションIDを維持するために使用される値のリスト
アップリミットID:
	トランザクションIDの最小IDをtrx_listリストに記録する
下限ID:
	読み取りビューが生成されたときに、システムはまだ次のトランザクションIDを割り当てていません。

1. まず、DB_TRX_ID < up_limit_id かどうかを判断します。up_limit_id 未満の場合、現在のトランザクションは DB_TRX_ID が配置されているレコードを見ることができます。以上である場合は、次の判断に進みます。 2. DB_TRX_ID >= low_limit_id かどうかを判断します。以上である場合は、DB_TRX_ID が配置されているレコードは Read View が生成された後にのみ表示されるため、現在のトランザクションには確実に表示されません。未満である場合は、次の判断に進みます。 3. DB_TRX_ID がアクティブなトランザクション内にあるかどうかを判断します。そうである場合は、Read View の生成時に、このトランザクションはまだアクティブであり、コミットされていないことを意味します。変更されたデータは、現在のトランザクションからは見ることができません。そうでない場合は、Read View が生成される前にこのトランザクションがコミットされているため、変更された結果を見ることができることを意味します。