【MySQL】MySQL的四种事务隔离级别
【MySQL】MySQL的四种事务隔离级别
本文实验的测试环境：Windows 10+cmd+MySQL5.6.36+InnoDBhtml
1、事务的基本要素（ACID）mysql
一、原子性（Atomicity）：事务开始后全部操做，要么所有作完，要么所有不作，不可能停滞在中间环节。事务执行过程当中出错，会回滚到事务开始前的状态，全部的操做就像没有发生同样。也就是说事务是一个不可分割的总体，就像化学中学过的原子，是物质构成的基本单位。sql
二、一致性（Consistency）：事务开始前和结束后，数据库的完整性约束没有被破坏 。好比A向B转帐，不可能A扣了钱，B却没收到。
数据库
三、隔离性（Isolation）：同一时间，只容许一个事务请求同一数据，不一样的事务之间彼此没有任何干扰。好比A正在从一张银行卡中取钱，在A取钱的过程结束前，B不能向这张卡转帐。session
四、持久性（Durability）：事务完成后，事务对数据库的全部更新将被保存到数据库，不能回滚。并发
小结：原子性是事务隔离的基础，隔离性和持久性是手段，最终目的是为了保持数据的一致性。app
2、事务的并发问题ide
一、脏读：事务A读取了事务B更新的数据，而后B回滚操做，那么A读取到的数据是脏数据高并发
二、不可重复读：事务 A 屡次读取同一数据，事务 B 在事务A屡次读取的过程当中，对数据做了更新并提交，致使事务A屡次读取同一数据时，结果 不一致。性能
三、幻读：系统管理员A将数据库中全部学生的成绩从具体分数改成ABCDE等级，可是系统管理员B就在这个时候插入了一条具体分数的记录，当系统管理员A改结束后发现还有一条记录没有改过来，就好像发生了幻觉同样，这就叫幻读。
小结：不可重复读的和幻读很容易混淆，不可重复读侧重于修改，幻读侧重于新增或删除。解决不可重复读的问题只需锁住知足条件的行，解决幻读须要锁表
3、MySQL事务隔离级别
| 事务隔离级别 | 脏读 | 不可重复读 | 幻读 |
| 读未提交（read-uncommitted） | 是 | 是 | 是 |
| 不可重复读（read-committed） | 否 | 是 | 是 |
| 可重复读（repeatable-read） | 否 | 否 | 是 |
| 串行化（serializable） | 否 | 否 | 否 |
mysql默认的事务隔离级别为repeatable-read
4、用例子说明各个隔离级别的状况
一、读未提交：
（1）打开一个客户端A，并设置当前事务模式为read uncommitted（未提交读），查询表account的初始值：
（2）在客户端A的事务提交以前，打开另外一个客户端B，更新表account：
（3）这时，虽然客户端B的事务还没提交，可是客户端A就能够查询到B已经更新的数据：
（4）一旦客户端B的事务由于某种缘由回滚，全部的操做都将会被撤销，那客户端A查询到的数据其实就是脏数据：
（5）在客户端A执行更新语句update account set balance = balance - 50 where id =1，lilei的balance没有变成350，竟然是400，是否是很奇怪，数据的一致性没问啊，若是你这么想就太天真 了，在应用程序中，咱们会用400-50=350，并不知道其余会话回滚了，要想解决这个问题能够采用读已提交的隔离级别
二、读已提交
（1）打开一个客户端A，并设置当前事务模式为read committed（未提交读），查询表account的初始值：
（2）在客户端A的事务提交以前，打开另外一个客户端B，更新表account：
（3）这时，客户端B的事务还没提交，客户端A不能查询到B已经更新的数据，解决了脏读问题：
（4）客户端B的事务提交
（5）客户端A执行与上一步相同的查询，结果 与上一步不一致，即产生了不可重复读的问题，在应用程序中，假设咱们处于客户端A的会话，查询到lilei的balance为450，可是其余事务将lilei的balance值改成400，咱们并不知道，若是用450这个值去作其余操做，是有问题的，不过这个几率真的很小哦，要想避免这个问题，能够采用可重复读的隔离级别
三、可重复读
（1）打开一个客户端A，并设置当前事务模式为repeatable read，查询表account的初始值：
（2）在客户端A的事务提交以前，打开另外一个客户端B，更新表account并提交，客户端B的事务竟然能够修改客户端A事务查询到的行，也就是mysql的可重复读不会锁住事务查询到的行，这一点出乎个人意料，sql标准中事务隔离级别为可重复读时，读写操做要锁行的，mysql竟然没有锁，我了个去。在应用程序中要注意给行加锁，否则你会以步骤（1）中lilei的balance为400做为中间值去作其余操做
（3）在客户端A执行步骤（1）的查询：
（4）执行步骤（1），lilei的balance仍然是400与步骤（1）查询结果一致，没有出现不可重复读的 问题；接着执行update balance = balance - 50 where id = 1，balance没有变成400-50=350，lilei的balance值用的是步骤（2）中的350来算的，因此是300，数据的一致性却是没有被破坏，这个有点神奇，也许是mysql的特点吧
mysql> select * from account; +------+--------+---------+ | id | name | balance | +------+--------+---------+ | 1 | lilei | 400 | | 2 | hanmei | 16000 | | 3 | lucy | 2400 | +------+--------+---------+ 3 rows in set (0.00 sec) mysql> update account set balance = balance - 50 where id = 1; Query OK, 1 row affected (0.00 sec) Rows matched: 1 Changed: 1 Warnings: 0 mysql> select * from account; +------+--------+---------+ | id | name | balance | +------+--------+---------+ | 1 | lilei | 300 | | 2 | hanmei | 16000 | | 3 | lucy | 2400 | +------+--------+---------+ 3 rows in set (0.00 sec)
(5) 在客户端A开启事务，查询表account的初始值
mysql> start transaction; Query OK, 0 rows affected (0.00 sec) mysql> select * from account; +------+--------+---------+ | id | name | balance | +------+--------+---------+ | 1 | lilei | 300 | | 2 | hanmei | 16000 | | 3 | lucy | 2400 | +------+--------+---------+ 3 rows in set (0.00 sec)
（6）在客户端B开启事务，新增一条数据，其中balance字段值为600，并提交
mysql> start transaction; Query OK, 0 rows affected (0.00 sec) mysql> insert into account values(4,'lily',600); Query OK, 1 row affected (0.00 sec) mysql> commit; Query OK, 0 rows affected (0.01 sec)
(7) 在客户端A计算balance之和，值为300+16000+2400=18700，没有把客户端B的值算进去，客户端A提交后再计算balance之和，竟然变成了19300，这是由于把客户端B的600算进去了
，站在客户的角度，客户是看不到客户端B的，它会以为是天下掉馅饼了，多了600块，这就是幻读，站在开发者的角度，数据的 一致性并无破坏。可是在应用程序中，咱们得代码可能会把18700提交给用户了，若是你必定要避免这状况小几率情况的发生，那么就要采起下面要介绍的事务隔离级别“串行化”
mysql> select sum(balance) from account;
+--------------+
| sum(balance) |
+--------------+
| 18700 |
+--------------+
1 row in set (0.00 sec)
mysql> commit;
Query OK, 0 rows affected (0.00 sec)
mysql> select sum(balance) from account;
+--------------+
| sum(balance) |
+--------------+
| 19300 |
+--------------+
1 row in set (0.00 sec)
4.串行化
（1）打开一个客户端A，并设置当前事务模式为serializable，查询表account的初始值：
mysql> set session transaction isolation level serializable; Query OK, 0 rows affected (0.00 sec) mysql> start transaction; Query OK, 0 rows affected (0.00 sec) mysql> select * from account; +------+--------+---------+ | id | name | balance | +------+--------+---------+ | 1 | lilei | 10000 | | 2 | hanmei | 10000 | | 3 | lucy | 10000 | | 4 | lily | 10000 | +------+--------+---------+ 4 rows in set (0.00 sec)
（2）打开一个客户端B，并设置当前事务模式为serializable，插入一条记录报错，表被锁了插入失败，mysql中事务隔离级别为serializable时会锁表，所以不会出现幻读的状况，这种隔离级别并发性极低，每每一个事务霸占了一张表，其余成千上万个事务只有干瞪眼，得等他用完提交才可使用，开发中不多会用到。
mysql> set session transaction isolation level serializable; Query OK, 0 rows affected (0.00 sec) mysql> start transaction; Query OK, 0 rows affected (0.00 sec) mysql> insert into account values(5,'tom',0); ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
补充：
一、SQL规范所规定的标准，不一样的数据库具体的实现可能会有些差别
二、mysql中默认事务隔离级别是可重复读时并不会锁住读取到的行
三、事务隔离级别为串行化时，读取数据会锁住整张表
四、阅读此文时，若是站在开发者的角度，也许会以为不可重复读和幻读，在逻辑上并无什么问题，最终数据仍然是一致的，可是站在用户的角度，他们一般只能看到一个事务（只能看到客户端A，不知道客户端B这个卧底的存在），而不会考虑事务并发执行的现象，一旦出现同一数据屡次读取结果不一样，或者凭空出现新记录，他们可能会产生疑虑，这是用户体验的问题。
5.事务在mysql中执行时，最终的结果不会出现数据的一致性的问题，由于在一个事务中，mysql执行某个操做未必会使用前一个操做的中间结果，它会根据其余并发事务的实际状况采来处理，看起来不合逻辑，可是保证了数据的一致性 ；可是事务在应用程序中执行时，一个操做的结果会被下一个操做用到，并进行其余的计算。这是咱们得当心，可重复读的时候应该锁行，串行化时 要锁表，否则会破坏数据的一致性。
六、事务在mysql中执行时，mysql会根据各个事务的实际状况综合处理，致使数据的一致性没有被破坏，可是应用程序时按照逻辑套路来出牌，并无mysql聪明，不免会出现数据的一致性问题。
七、隔离级别越高，越能保证数据的完整性和一致性，可是对并发性能的影响也越大，鱼和熊掌不可兼得啊。对于多数应用程序，能够优先考虑把数据库系统的隔离级别设为Read Committed，它可以避免脏读取，并且具备较好的并发性能。尽管它会致使不可重复读、幻读这些并发问题，在可能出现这类问题的个别场合，能够由应用程序采用悲观锁或乐观锁来控制。
Innodb幻读的各类姿式
导读
认识幻读，了解在应用开发中，高并发状况下可能形成的数据不一致问题。
----MySQL支持事务隔离级别----
MySQL默认事务隔离级别： REPEATABLE READ 为了提升并发度建议调整为：READ COMMITTED.
MySQL支持事务隔离级别：
未提交读（READ UNCOMMITTED）：另外一个事务修改了数据，但还没有提交，而本事务中的SELECT会读到这些未被提交的数据（脏读）。
提交读（READ COMMITTED）：本事务读取到的是最新的数据（其余事务提交后的）。问题是，在同一个事务里，先后两次相同的SELECT会读到不一样的结果（不重复读）。
可重复读（REPEATABLE READ）：在同一个事务里，SELECT的结果是事务开始时时间点的状态，所以，一样的SELECT操做读到的结果会是一致的。可是，会有幻读现象。
串行化（SERIALIZABLE）：读操做会隐式获取共享锁，能够保证不一样事务间的互斥。（这个表级高了的串行控制，不是实例级别的）
----重点名词解析----
脏读： 最容易理解。 另外一个事务修改的数据，还没提交，而本事务中的SELECT语句读取到数据。
不可重复读（提交读）： 把脏读搞定后，可能会遇到另外一个问题，提交读。 事务中两次一样的SELECT语句读取到不一样的结果。
幻读（一致性读）：解决不可重复读的问题后，能够保证同一个事情里，查询的结果都是事务开始的状态（一致性）。可是，若是另外一个事务同时提交了数据，本事务更新时，就会惊奇的发现，这些数据好象是以前读到的。
三组实验
1、准备实验环境
create database zst;
use zst;
create table a1(
id int not null,
name varchar(32),
primary key (id)) engine=innodb;
确认事务隔离级别在rr下：
mysql> select @@global.tx_isolation, @@tx_isolation;
+———————————-+————————-+
| @@global.tx_isolation | @@tx_isolation |
+———————————-+————————-+
| REPEATABLE-READ | REPEATABLE-READ |
+———————————-+————————-+
2、开始实验
一、实验一
| session 1 | session 2 |
|---|---|
| begin; select * from a1; Empty set (0.01 sec) |
begin; |
| insert into a1 values(1,’zhishutang.com’); | |
| select * from a1; Empty set (0.01 sec) |
|
| commit; | |
| select * from a1; Empty set (0.01 sec) |
|
| insert into a1 values(1,’wubx’); ERROR 1062 (23000): Duplicate entry ‘1’ for key ‘PRIMARY’ |
_ |
实验结果：查的没数据，但实际写入失败！！！ 还好是写入失败，于是不会影响太大。
二、实验二
此次来一个更猛一点的：
| session 1 | session 2 |
|---|---|
| truncate a1 ; insert into a1 values(1,’a1’),(2,’a2’),(3,’a3’); |
|
| begin; | begin; |
| select * from a1 | select * from a1; |
| 1, a1 2, a2 3, a3 3 rows in set (0.00 sec) |
1, a1 2, a2 3, a3 3 rows in set (0.00 sec) |
| delete from a1 where id=1; commit; |
|
| select * from a1 | select * from a1; |
| 1, a1 2, a2 3, a3 3 rows in set (0.00 sec) |
2, a2 3, a3 2 rows in set (0.00 sec) |
| update a1 set name=’wubx’; Query OK, 2 rows affected (0.00 sec) Rows matched: 2 Changed: 2 Warnings: 0 |
|
| select * from a1 | select * from a1; |
| 1, a1 2, wubx 3, wubx 3 rows in set (0.00 sec) |
2, a2 3, a3 2 rows in set (0.00 sec) |
| commit Query OK, 0 rows affected (0.00 sec) |
_ |
实验结果：天杀的update更新，提示成功，却看到一行老数据，无论更新几回，那个老数据还在。commit后消失原来那行老数据丢失。
另外，该过程也适用于insert：
| session 1 | session 2 |
|---|---|
| truncate a1 ; | |
| begin; | begin; |
| insert into a1 values(1,’a1’); | insert into a1 values(2,’abc’); |
| select * from a1 | select * from a1 |
| 1, a1 | 2,abc |
| commit | |
| select * from a1 | select * from a1 |
| 1, a1 | 2,abc |
| update a1 set name=’zhishutang.com’; Query OK, 2 rows affected (0.00 sec) Rows matched: 2 Changed: 2 Warnings: 0 |
|
| select * from a1 | select * from a1 |
| 1, zhishutang.com 2, zhishutang.com |
2.abc |
| rollback | |
| select * from a1 | select * from a1 |
| 2, abc | 2, abc |
实验结果：在本操做中，Session 1是读取到一条，但作一个次update更新后能够看到2条记录，这个也能够说是事务的一个幻读，但这个事务并无被破坏，rollback还能把Session 1的操做撤掉。
附：其实这种情形在官方手册里也有标注，以下：
https://dev.mysql.com/doc/refman/5.7/en/innodb-consistent-read.html
The snapshot of the database state applies to SELECT statements within a transaction, not necessarily to DML statements. If you insert or modify some rows and then commit that transaction, a DELETE or UPDATE statement issued from another concurrent REPEATABLE READ transaction could affect those just-committed rows, even though the session could not query them. If a transaction does update or delete rows committed by a different transaction, those changes do become visible to the current transaction.
三、实验三
https://dev.mysql.com/doc/refman/5.7/en/innodb-consistent-read.html
If you want to see the “freshest” state of the database, use either the READ COMMITTED isolation level or a locking read:
| session 1 | session 2 |
|---|---|
| insert into a1 values(1,’a1’); | insert into a1 values(2,’abc’); |
| 1, a1 | 2,abc |
| commit | |
| select * from a1 | select * from a1 |
| 1, a1 | 2,abc |
| commit | |
| select * from a1 | |
| 1,a1 | |
| select * from a1 lock in share mode; | |
| 1,a1 2, abc |
|
| select * from a1 for update; | |
| 1,a1 2, abc |
|
| select * from a1 | |
| 1,a1 | _ |
总结
一、在RR隔离级别下能够获得一致性的读。
二、对于DML操做，容易出现幻读问题，在程序设计时，须要注意并行设计这块。
三、事务处理中，为了获得新数据，也能够考虑利用显式锁的形式来获取最新数据。
四、特别注意该表在事务操做中会Block DDL操做。—这个没补实验，各位自补。
- 1. MySQL的四种事务隔离级别
- 2. MySQL 的四种事务隔离级别
- 3. mysql 事务的四种隔离级别
- 4. MySQL 四种事务隔离级别
- 5. mysql四种事务隔离级别
- 6. MySQL InnoDB 四种事务隔离级别
- 7. Mysql 四种事务隔离级别
- 8. MYSQL的四种事物隔离级别
- 9. MySQL四种隔离级别
- 更多相关文章...
- • 事务的四大特性和隔离级别 - Hibernate教程
- • MySQL事务（TRANSACTION） - MySQL教程
- • 漫谈MySQL的锁机制
- • Docker容器实战(六) - 容器的隔离与限制
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. MySQL的四种事务隔离级别
- 2. MySQL 的四种事务隔离级别
- 3. mysql 事务的四种隔离级别
- 4. MySQL 四种事务隔离级别
- 5. mysql四种事务隔离级别
- 6. MySQL InnoDB 四种事务隔离级别
- 7. Mysql 四种事务隔离级别
- 8. MYSQL的四种事物隔离级别
- 9. MySQL四种隔离级别