| いいえ＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃ 4. 4 つの分離レベルの SQL デモ
mysql バージョン: 5.6
ストレージ エンジン: InnoDB
ツール: navicat
テーブル ステートメント: CREATE TABLE `tb_bank` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`name` varchar(16) COLLATE utf8_bin DEFAULT NULL,
`account` int(11) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;
INSERT INTO `demo`.`tb_bank`(`id`, `name`, `account`) VALUES (1, '小明', 1000); ログイン後にコピー 1. SQL でデモンストレーションする ------read-uncommitted ダーティ リーディング (2)read-uncommit によるダーティ リーディング いわゆるダーティ リーディングたとえば、2 つのトランザクションがあり、一方のトランザクションはもう一方のトランザクションのコミットされていないデータを読み取ることができます。
シナリオ: セッション 1 は 200 元を送金したいと考えており、セッション 2 は 100 元を送金します。基本は1000です。正常に完了した場合の正しい結果は 900 元であるはずです。ただし、何らかの理由で session2 がトランザクション ロールバックに転送されたとします。この時点での正しい結果は 800 元です。 デモ手順:
① 2 つの新しいセッション (セッションは、navicat では 2 つのクエリ ウィンドウとして表示され、mysql コマンド ラインでも 2 つのウィンドウとして表示されます) を作成し、それぞれ select @@tx_isolation;//查询当前事务隔离级别
set session transaction isolation level read uncommitted;//将事务隔离级别设置为 读未提交 ログイン後にコピー を実行します。 ② 両方のセッションでトランザクションがオープン start transaction;//开启事务 ログイン後にコピー ③ セッション 1 とセッション 2: 2 つの操作が実行される前の口座残高が 1000 select * from tb_bank where id=1;//查询结果为1000 ログイン後にコピー であることを証明します。 ④ セッション 2: この時点で、更新が行われたと仮定します。 session2 のものが最初に実行されます。 update tb_bank set account = account + 100 where id=1; ログイン後にコピー ⑤ session1: session1 は session2 がコミットする前に実行を開始します。 select * from tb_bank where id=1;//查询结果：1100 ログイン後にコピー ⑥ session2: 何らかの理由で転送が失敗し、トランザクションがロールバックされました。 rollback;//事务回滚
commit;//提交事务 ログイン後にコピー ⑦ この時点でセッション1の転送が始まり、セッション1は⑤のクエリ結果1100が正しいデータであると感じます。 update tb_bank set account=1100-200 where id=1;
commit; ログイン後にコピー ⑧セッション 1 とセッション 2 のクエリ結果 select * from tb_bank where id=1;//查询结果：900 ログイン後にコピー この時点で、セッション 1 のダーティ リードにより最終データが不一致であることがわかりました。正しい結果は 800 であるはずです。
この時点でダーティ リーディングを回避し、トランザクションの分離レベルを読み取りコミットまで高めるにはどうすればよいでしょうか #(2) 読み取りコミットはダーティー リーディングを解決しますデータをリセットし、account=1000にデータを復元します① 新しいセッションを2つ作成し、それぞれ設定します set session transaction isolation level read committed;//将隔离级别设置为 不可重复读 ログイン後にコピー select * from tb_bank where id=1;//查询结果为1000，这说明 不可重复读 隔离级别有效的隔离了两个会话的事务。 ログイン後にコピー READ COMMITTED 分離レベルでは、読み取りごとにスナップショットが再生成されるため、各スナップショットは最新となり、したがってトランザクション内の各 SELECT は他のコミットされたトランザクションによって加えられた変更も確認できます
シナリオ : セッション 1 がアカウント クエリを実行します、セッション 2 は 100 のアカウント転送を実行します。
セッション 1 は、アカウントのクエリと更新を行うトランザクションを開きます。このとき、セッション 2 もアカウントのトランザクションを開いて更新します。正しい結果は、セッション 1 がトランザクションを開始した後にクエリによって読み取られた結果が同じであることです。
① 2 つの新しいセッションを作成し、それぞれ set session transaction isolation level read committed; ログイン後にコピー start transaction; ログイン後にコピー select * from tb_bank where id=1;//查询结果：1000 ログイン後にコピー update tb_bank set account = account+100 where id=1;
select * from tb_bank where id=1;//查询结果：1100 ログイン後にコピー select * from tb_bank where id=1;//查询结果：1100。和③中查询结果对比，session1两次查询结果不一致。 ログイン後にコピー
① 新しいセッションを2つ作成し、
set session transaction isolation level repeatable read; ログイン後にコピー ⑤ session1 の 2 番目のクエリを繰り返します:
select * from tb_bank where id=1;//查询结果为：1000 ログイン後にコピー 操作続行:
⑥ セッション 1 が 100 に転送:
update tb_bank set account=account+100 where id=1; ログイン後にコピー 在业务逻辑中，通常我们先获取数据库中的数据，然后在业务中判断该条件是否符合自己的业务逻辑，如果是的话，那么就可以插入一部分数据。但是mysql的快照读可能在这个过程中会产生意想不到的结果。
场景模拟：
session1开启事务，先查询有没有小张的账户信息，没有的话就插入一条。这是session2也执行和session1同样的操作。 准备工作：插入两条数据 INSERT INTO `demo`.`tb_bank`(`id`, `name`, `account`) VALUES (2, '小红', 800);
INSERT INTO `demo`.`tb_bank`(`id`, `name`, `account`) VALUES (3, '小磊', 6000); ログイン後にコピー （1）repeatable-read的幻读 ① 新建两个session都执行 set session transaction isolation level repeatable read;
start transaction;
select * from tb_bank;//查询结果：（这一步很重要，直接决定了快照生成的时间） ログイン後にコピー 结果都是： 
② session2插入数据
INSERT INTO `demo`.`tb_bank`(`id`, `name`, `account`) VALUES (4, '小张', 8000);
select * from tb_bank; ログイン後にコピー 
结果数据插入成功。此时session2提交事务 ③ session1进行插入
插入之前我们先看一下当前session1是否有id=4的数据 select * from tb_bank; ログイン後にコピー 
结果session1中没有该条记录，这时按照我们通常的业务逻辑，此时应该是能成功插入id=4的数据。继续执行： INSERT INTO `demo`.`tb_bank`(`id`, `name`, `account`) VALUES (4, '小张', 8000); ログイン後にコピー 
结果插入失败，提示该条已经存在，但是我们查询里面并没有这一条数据啊。为什么会插入失败呢？ 因为①中的select语句生成了快照，之后的读操作（未加读锁）都是进行的快照读，即在当前事务结束前，所有的读操作的结果都是第一次快照读产生的快照版本。疑问又来了，为什么②步骤中的select语句读到的不是快照版本呢？因为update语句会更新当前事务的快照版本。具体参阅第五章节。 （2）repeatable-read利用当前读解决幻读重复（1）中的①②
③ session1进行插入
插入之前我们先看一下当前session1是否有id=4的数据 select * from tb_bank; ログイン後にコピー 结果session1中没有该条记录，这时按照我们通常的业务逻辑，此时应该是能成功插入id=4的数据。 select * from tb_bank lock in share mode;//采用当前读 ログイン後にコピー 结果：发现当前结果中已经有小张的账户信息了，按照业务逻辑，我们就不在继续执行插入操作了。
这时我们发现用当前读避免了repeatable-read隔离级别下的幻读现象。
4、serializable隔离级别
在此级别下我们就不再做serializable的避免幻读的sql演示了，毕竟是给整张表都加锁的。
五、当前读和快照读
本想把当前读和快照读单开一片博客，但是为了把幻读总结明白，暂且在本章节先简单解释下快照读和当前读。后期再追加一篇MVCC，next-key的博客吧。。。
1、快照读：即一致非锁定读。
① InnoDB存储引擎下，查询语句默认执行快照读。
② RR隔离级别下一个事务中的第一次读操作会产生数据的快照。
③ update，insert，delete操作会更新快照。
四种事务隔离级别下的快照读区别：
① read-uncommitted和read-committed级别：每次读都会产生一个新的快照，每次读取的都是最新的，因此RC级别下select结果能看到其他事务对当前数据的修改，RU级别甚至能读取到其他未提交事务的数据。也因此这两个级别下数据是不可重复读的。
② repeatable-read级别：基于MVCC的并发控制，并发性能极高。第一次读会产生读数据快照，之后在当前事务中未发生快照更新的情况下，读操作都会和第一次读结果保持一致。快照产生于事务中，不同事务中的快照是完全隔离的。
③ serializable级别：从MVCC并发控制退化为基于锁的并发控制。不区别快照读与当前读，所有的读操作均为当前读，读加读锁 (S锁)，写加写锁 (X锁)。Serializable隔离级别下，读写冲突，因此并发度急剧下降。（锁表，不建议使用）
2、当前读：即一致锁定读。
如何产生当前读
① select ... lock in share mode
② select ... for update
③ update，insert，delete操作都是当前读。
读取之后，还需要保证当前记录不能被其他并发事务修改，需要对当前记录加锁。①中对读取记录加S锁 (共享锁)，②③X锁 (排它锁)。
3、疑问总结
① update，insert，delete操作为什么都是当前读？
简单来说，不执行当前读，数据的完整性约束就有可能遭到破坏。尤其在高并发的环境下。
分析update语句的执行步骤：update table set ... where ...;
InnoDB エンジンは最初に where クエリを実行します。クエリされた結果セットは最初の項目から読み取りを開始し、次に更新操作を実行し、次に 2 番目のデータを読み取り、更新操作を実行します...つまり、更新を実行するたびに現在の読み取りが伴います。削除の場合も同様で、結局のところ、データを削除するには、まずデータが見つかる必要があります。挿入の場合は少し異なり、挿入操作を実行する前に一意のキーのチェックを実行する必要があります。 [関連する推奨事項: MySQL チュートリアル ]
|
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
