AI 助理
文档备案控制台
开发者社区 数据库 文章 正文

MySQL事务隔离级别解密

2018-08-11 1515
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
本文涉及的产品
RDS MySQL DuckDB 分析主实例，基础系列 4核8GB
RDS MySQL DuckDB 分析主实例，集群系列 4核8GB
RDS AI 助手，专业版
简介： READ UNCOMMITTED 未提交读  在READ UNCOMMITTED级别，事务中的修改，即使没有提交，对其他事务也都是可见的。
  1. READ UNCOMMITTED 未提交读 
    在READ UNCOMMITTED级别，事务中的修改，即使没有提交，对其他事务也都是可见的。事务可以读取未提交的数据，这也被称作脏读。这个级别会导致很多问题，从性能上来说，READ UNCOMMITTED不会比其他的级别好太多，但确缺乏其他级别的很多好处，除非真的有必要的理由，在实际应用中一般很少使用。
  2. READ COMMITED 提交读 
    大多数数据库系统的默认隔离级别是 READ COMMITED（但mysql不是）。READ COMMITED满足前面提到的隔离性简单定义：一个事务开始时，只能看见已经提交的事务所做的修改。换句话说，一个事务从开始直到提交之前，所做的任何修改对其他事务都是不可见的。这个级别有时候也叫做不可重复读，因为两次执行同样的查询，可能会得到不一样的结果。
  3. REPEATABLE READ 可重复写 
    MySQL的默认事务隔离级别。 
    REPEATABLE READ解决了脏读的问题。该级别保证了在同一个事务中多次读取同样的记录的结果是一致的。但是理论上，可重复读隔离级别还是无法解决另一个幻读的问题。所谓幻读，指的是当某个事务在读取某个范围内的记录时，另外一个事务又在该范围内插入了新的记录，当之前的事务再次读取该范围的记录时，会产生幻行。InnoDB存储引擎通过多版本并发控制（MVCC）解决了幻读的问题。
  4. SERIALIZABLE 可串行化 
    SERIALIZABLE 是最高的隔离级别。它通过强事务串行执行，避免了前面说的幻读的问题。简单来说，SERIALIZABLE会在曲度的每一行数据都加上锁，所以可能导致大量的超时和锁争用的问题。实际应用中也很少用到这个隔离级别，只有在非常需要确保数据一致性而且可以接受没有并发的情况下，才考虑使用该级别。

实验

上面是摘自《高性能MySQL》一书，光这么看，可能也理解不到多少东西，不如直接做实验亲身体验一下，加深理解。

我们先简单创建一个表 users，结构如下：

+------------+------------------+------+-----+-------------------+----------------+
| Field      | Type             | Null | Key | Default           | Extra          |
+------------+------------------+------+-----+-------------------+----------------+
| id         | int(11) unsigned | NO   | PRI | <null>            | auto_increment |
| name       | varchar(50)      | NO   |     |                   |                |
| created_at | datetime         | NO   |     | CURRENT_TIMESTAMP |                |
| updated_at | datetime         | NO   |     | CURRENT_TIMESTAMP |                |
| deleted_at | datetime         | YES  |     | <null>            |                |
+------------+------------------+------+-----+-------------------+----------------+

实现插入三条数据：

+----+-------------+---------------------+---------------------+------------+
| id | name        | created_at          | updated_at          | deleted_at |
+----+-------------+---------------------+---------------------+------------+
| 1  | coolcao2018 | 2018-05-28 12:48:43 | 2018-05-28 12:48:43 | <null>     |
| 2  | tom         | 2018-05-28 13:24:28 | 2018-05-28 13:24:28 | <null>     |
| 3  | lili        | 2018-05-31 08:54:28 | 2018-05-31 08:54:28 | <null>     |
+----+-------------+---------------------+---------------------+------------+

然后打开两个终端，A和B分别表示两个用户同时在操作。

READ UNCOMMITTED

对于用户A，操作：

mysql root@localhost:test> set session transaction isolation level read uncommitted;
mysql root@localhost:test> start transaction;
mysql root@localhost:test> select * from users;
+----+-------------+---------------------+---------------------+------------+
| id | name        | created_at          | updated_at          | deleted_at |
+----+-------------+---------------------+---------------------+------------+
| 1  | coolcao2018 | 2018-05-28 12:48:43 | 2018-05-28 12:48:43 | <null>     |
| 2  | tom         | 2018-05-28 13:24:28 | 2018-05-28 13:24:28 | <null>     |
| 3  | lili        | 2018-05-31 08:54:28 | 2018-05-31 08:54:28 | <null>     |
+----+-------------+---------------------+---------------------+------------+

然后，用户B操作，

mysql root@localhost:test> set session transaction isolation level read uncommitted;
mysql root@localhost:test> start transaction;
mysql root@localhost:test> update users set name='coolcao' where id=1;

此时，用户B并未提交事务，用户A进行查询操作看看：

mysql root@localhost:test> select * from users;
+----+---------+---------------------+---------------------+------------+
| id | name    | created_at          | updated_at          | deleted_at |
+----+---------+---------------------+---------------------+------------+
| 1  | coolcao | 2018-05-28 12:48:43 | 2018-05-28 12:48:43 | <null>     |
| 2  | tom     | 2018-05-28 13:24:28 | 2018-05-28 13:24:28 | <null>     |
| 3  | lili    | 2018-05-31 08:54:28 | 2018-05-31 08:54:28 | <null>     |
+----+---------+---------------------+---------------------+------------+

从整个过程来看，用户B还并未提交事务，但是A却已经能够直接读到B的更新。

从上面实验结果来看，不难理解上面对于 READ UNCOMMITTED级别的描述： 在READ UNCOMMITTED级别，事务中的修改，即使没有提交，对其他事务也都是可见的。

READ COMMITTED

同时将A，B两个终端的事务级别设置为 read committed:

// 在A，B两个终端都执行
set session transaction isolation level read committed;

对于A，我们开启一个事务，然后更新一下数据，但并不提交事务：

mysql root@localhost:test>  set session transaction isolation level read committed;
mysql root@localhost:test> start transaction;
mysql root@localhost:test> select * from users;
+----+---------+---------------------+---------------------+------------+
| id | name    | created_at          | updated_at          | deleted_at |
+----+---------+---------------------+---------------------+------------+
| 1  | coolcao | 2018-05-28 12:48:43 | 2018-05-28 12:48:43 | <null>     |
| 2  | tom     | 2018-05-28 13:24:28 | 2018-05-28 13:24:28 | <null>     |
| 3  | lili    | 2018-05-31 08:54:28 | 2018-05-31 08:54:28 | <null>     |
+----+---------+---------------------+---------------------+------------+
mysql root@localhost:test> update users set name='coolcao222' where id=1;
mysql root@localhost:test> select * from users;
+----+------------+---------------------+---------------------+------------+
| id | name       | created_at          | updated_at          | deleted_at |
+----+------------+---------------------+---------------------+------------+
| 1  | coolcao222 | 2018-05-28 12:48:43 | 2018-05-28 12:48:43 | <null>     |
| 2  | tom        | 2018-05-28 13:24:28 | 2018-05-28 13:24:28 | <null>     |
| 3  | lili       | 2018-05-31 08:54:28 | 2018-05-31 08:54:28 | <null>     |
+----+------------+---------------------+---------------------+------------+

然后，在B终端，开启另外一个事务，进行数据查询：

mysql root@localhost:test> set session transaction isolation level read committed;
mysql root@localhost:test> start transaction;
mysql root@localhost:test> select * from users;
+----+---------+---------------------+---------------------+------------+
| id | name    | created_at          | updated_at          | deleted_at |
+----+---------+---------------------+---------------------+------------+
| 1  | coolcao | 2018-05-28 12:48:43 | 2018-05-28 12:48:43 | <null>     |
| 2  | tom     | 2018-05-28 13:24:28 | 2018-05-28 13:24:28 | <null>     |
| 3  | lili    | 2018-05-31 08:54:28 | 2018-05-31 08:54:28 | <null>     |
+----+---------+---------------------+---------------------+------------+

然后，将A事务提交：

commit;

这时，再在B查询 ：

mysql root@localhost:test> select * from users;
+----+------------+---------------------+---------------------+------------+
| id | name       | created_at          | updated_at          | deleted_at |
+----+------------+---------------------+---------------------+------------+
| 1  | coolcao222 | 2018-05-28 12:48:43 | 2018-05-28 12:48:43 | <null>     |
| 2  | tom        | 2018-05-28 13:24:28 | 2018-05-28 13:24:28 | <null>     |
| 3  | lili       | 2018-05-31 08:54:28 | 2018-05-31 08:54:28 | <null>     |
+----+------------+---------------------+---------------------+------------+

从结果来看，也不难理解 read committed级别，对于一个事务，只能读取到当前事务的数据和其他已经提交的事务的数据，对于其他未提交事务的数据，读不到。

而且，从上面的实验结果中，我们也看到了，会话B在会话A提交事务前后查询的结果并不一致，这也就是上面所说的，不可重复读。

REPEATABLE READ 可重复读

我们将会话A设置为REPEATABLE READ :

mysql root@localhost:test> set session transaction isolation level repeatable read;
mysql root@localhost:test> start transaction;
mysql root@localhost:test> select * from users;
+----+---------+---------------------+---------------------+------------+
| id | name    | created_at          | updated_at          | deleted_at |
+----+---------+---------------------+---------------------+------------+
| 1  | coolcao | 2018-08-10 15:21:02 | 2018-08-10 15:21:02 | <null>     |
| 2  | tom     | 2018-08-10 15:21:07 | 2018-08-10 15:21:07 | <null>     |
| 3  | lili    | 2018-08-10 15:21:11 | 2018-08-10 15:21:11 | <null>     |
+----+---------+---------------------+---------------------+------------+

此时，我们在B终端插入一条数据：

mysql root@localhost:test> insert into users (id,name) values (4,'coco');
mysql root@localhost:test> commit;
mysql root@localhost:test> select * from users;
+----+---------+---------------------+---------------------+------------+
| id | name    | created_at          | updated_at          | deleted_at |
+----+---------+---------------------+---------------------+------------+
| 1  | coolcao | 2018-08-10 15:21:02 | 2018-08-10 15:21:02 | <null>     |
| 2  | tom     | 2018-08-10 15:21:07 | 2018-08-10 15:21:07 | <null>     |
| 3  | lili    | 2018-08-10 15:21:11 | 2018-08-10 15:21:11 | <null>     |
| 4  | coco    | 2018-08-10 15:23:50 | 2018-08-10 15:23:50 | <null>     |
+----+---------+---------------------+---------------------+------------+

在终端B中，插入一条记录，并提交，这时id=4的用户已经被插入到数据库。

此时，再回到终端A，查询：

mysql root@localhost:test> select * from users;
+----+---------+---------------------+---------------------+------------+
| id | name    | created_at          | updated_at          | deleted_at |
+----+---------+---------------------+---------------------+------------+
| 1  | coolcao | 2018-08-10 15:21:02 | 2018-08-10 15:21:02 | <null>     |
| 2  | tom     | 2018-08-10 15:21:07 | 2018-08-10 15:21:07 | <null>     |
| 3  | lili    | 2018-08-10 15:21:11 | 2018-08-10 15:21:11 | <null>     |
+----+---------+---------------------+---------------------+------------+

哎，查询的结果中，没有B刚插入的id=4的用户，这也就是说该级别的事务隔离，保证了在同一个事务中多次读取同样的记录的结果是一致的。这时，我们在A中插入一条记录：

mysql root@localhost:test> insert into users (id,name) values (4,'coco');
(1062, u"Duplicate entry '4' for key 'PRIMARY'")

哎，这个时候，数据库报错了，提示主键重复。明明我在这个事务中，查询的数据只有1,2,3，为什么插入4的时候提示主键冲突呢？是发生幻觉了么？是的，发生“幻读”了。由于REPEATABLE READ级别的隔离，在一个事务中，多次读取同样记录的结果是一致的，在这多次读取之间，被别的事务插入了新的数据，这时前事务再插入数据，必然会导致错误。

SERIALIZABLE 可串行化

我们将A，B同时设置为SERIALIZABLE, 然后在A开启是个事务，做一个简单查询：

mysql root@localhost:test> set session transaction isolation level serializable;
mysql root@localhost:test> start transaction;
mysql root@localhost:test> select * from users where id<10;
+----+---------+---------------------+---------------------+------------+
| id | name    | created_at          | updated_at          | deleted_at |
+----+---------+---------------------+---------------------+------------+
| 1  | coolcao | 2018-08-10 15:21:02 | 2018-08-10 15:21:02 | <null>     |
| 2  | tom     | 2018-08-10 15:21:07 | 2018-08-10 15:21:07 | <null>     |
| 3  | lili    | 2018-08-10 15:21:11 | 2018-08-10 15:21:11 | <null>     |
| 4  | coco    | 2018-08-10 15:23:50 | 2018-08-10 15:23:50 | <null>     |
| 5  | juli    | 2018-08-10 15:31:32 | 2018-08-10 15:31:32 | <null>     |
+----+---------+---------------------+---------------------+------------+

此时，A事务并未提交，然后在B再开启一个事务，进行插入操作：

mysql root@localhost:test> set session transaction isolation level serializable;
mysql root@localhost:test> start transaction;
mysql root@localhost:test> insert into users (id,name) values (6,'kate');
(1205, u'Lock wait timeout exceeded; try restarting transaction')

你会发现，哎我去，B事务被挂住了，然后过了一段时间，提示了错误 (1205, u'Lock wait timeout exceeded; try restarting transaction') ，说等待锁超时。

是的，在串行化级别，会在读取的每一行数据都加上锁，也就是说，上面A事务在读取时，已经加了锁，此时B事务在插入操作时，得等待锁的放开，时间一长，A锁未放开，B就报错了。

从实验中可以看出，可串行化级别，由于要保证避免幻读而加了锁导致效率以及可能会触发的等待锁超时等错误，实际应用中，该级别的事务隔离也很少使用。

对照着实验结果，来理解上面四个隔离级别，就容易理解了。

1、具有1-5工作经验的，面对目前流行的技术不知从何下手，需要突破技术瓶颈的可以加群。

2、在公司待久了，过得很安逸，但跳槽时面试碰壁。需要在短时间内进修、跳槽拿高薪的可以加群。

3、如果没有工作经验，但基础非常扎实，对java工作机制，常用设计思想，常用java开发框架掌握熟练的，可以加群。

4、觉得自己很牛B，一般需求都能搞定。但是所学的知识点没有系统化，很难在技术领域继续突破的可以加群。

5.群号 468947140，点击链接加入群聊【Java-BATJ企业级资深架构】：https://jq.qq.com/?_wv=1027&k=57VIGuh

6.阿里Java高级大牛直播讲解知识点，分享知识，知识点都是各位老师多年工作经验的梳理和总结，带着大家全面、科学地建立自己的技术体系和技术认知！

文章标签：
云数据库 RDS MySQL 版
关系型数据库
MySQL
Java
数据库
存储
开发框架
关键词：
云数据库 RDS MySQL 版事务
云数据库 RDS MySQL 版隔离级别
云数据库 RDS MySQL 版事务隔离级别
相关实践学习
如何快速连接云数据库RDS MySQL
本场景介绍如何通过阿里云数据管理服务DMS快速连接云数据库RDS MySQL，然后进行数据表的CRUD操作。
MySQL数据库入门学习
本课程通过最流行的开源数据库MySQL带你了解数据库的世界。 &nbsp; 相关的阿里云产品：云数据库RDS MySQL 版 阿里云关系型数据库RDS（Relational Database Service）是一种稳定可靠、可弹性伸缩的在线数据库服务，提供容灾、备份、恢复、迁移等方面的全套解决方案，彻底解决数据库运维的烦恼。 了解产品详情:&nbsp;https://www.aliyun.com/product/rds/mysql&nbsp;
欧阳愠斐
目录
相关文章
艾伦~耶格尔
|
6月前
|
SQL 关系型数据库 MySQL
MySQL锁机制：并发控制与事务隔离
本文深入解析了MySQL的锁机制与事务隔离级别，涵盖锁类型、兼容性、死锁处理及性能优化策略，助你掌握高并发场景下的数据库并发控制核心技巧。
艾伦~耶格尔
337 2
游客ei4oozwd2l7wm
|
7月前
|
存储 监控 Oracle
MySQL事务
MySQL事务具有ACID特性，包括原子性、一致性、隔离性和持久性。其默认隔离级别为可重复读，通过MVCC和间隙锁解决幻读问题，确保事务间数据的一致性和并发性。
游客ei4oozwd2l7wm
177 0
MySQL事务
技术自由圈/原疯狂创客圈
|
8月前
|
存储 SQL 关系型数据库
mysql底层原理：索引、慢查询、 sql优化、事务、隔离级别、MVCC、redolog、undolog（图解+秒懂+史上最全）
mysql底层原理：索引、慢查询、 sql优化、事务、隔离级别、MVCC、redolog、undolog（图解+秒懂+史上最全）
技术自由圈/原疯狂创客圈
2102 0
mysql底层原理：索引、慢查询、 sql优化、事务、隔离级别、MVCC、redolog、undolog（图解+秒懂+史上最全）
赵渝强老师
|
5月前
|
关系型数据库 MySQL 数据库
【赵渝强老师】MySQL的事务隔离级别
数据库并发访问时易引发数据不一致问题。如客户端读取到未提交的事务数据，可能导致“脏读”。MySQL通过四种事务隔离级别（读未提交、读已提交、可重复读、可序列化）控制并发行为，默认为“可重复读”，以平衡性能与数据一致性。
赵渝强老师
345 0
热夏resummer
|
6月前
|
关系型数据库 MySQL 数据库
MySql事务以及事务的四大特性
事务是数据库操作的基本单元，具有ACID四大特性：原子性、一致性、隔离性、持久性。它确保数据的正确性与完整性。并发事务可能引发脏读、不可重复读、幻读等问题，数据库通过不同隔离级别（如读未提交、读已提交、可重复读、串行化）加以解决。MySQL默认使用可重复读级别。高隔离级别虽能更好处理并发问题，但会降低性能。
热夏resummer
227 0
海绵小子
|
8月前
|
安全 关系型数据库 MySQL
mysql事务隔离级别
事务隔离级别用于解决脏读、不可重复读和幻读问题。不同级别在安全与性能间权衡，如SERIALIZABLE最安全但性能差，READ_UNCOMMITTED性能高但易导致数据不一致。了解各级别特性有助于合理选择以平衡并发性与数据一致性需求。
海绵小子
225 1
蓝易云
|
9月前
|
关系型数据库 MySQL 数据库
MySQL报错：未知系统变量'tx_isolation'及隔离级别查询
记住，选择合适的隔离级别，就像是在风平浪静的湖面上找到适合的划船速度——既要快到能赶上午饭（性能），又不至于翻船（数据一致性问题）。
蓝易云
363 3
蓝染-惣右介
|
SQL 安全 关系型数据库
【MySQL基础篇】事务（事务操作、事务四大特性、并发事务问题、事务隔离级别）
事务是MySQL中一组不可分割的操作集合，确保所有操作要么全部成功，要么全部失败。本文利用SQL演示并总结了事务操作、事务四大特性、并发事务问题、事务隔离级别。
蓝染-惣右介
5326 56
【MySQL基础篇】事务（事务操作、事务四大特性、并发事务问题、事务隔离级别）
技术自由圈/原疯狂创客圈
|
SQL 关系型数据库 MySQL
京东面试：MySQL MVCC是如何实现的？如何通过MVCC实现读已提交、可重复读隔离级别的？
1.请解释什么是MVCC，它在数据库中的作用是什么？ 2.在MySQL中，MVCC是如何实现的？请简述其工作原理。 3.MVCC是如何解决读-写和写-写冲突的？ 4.在并发环境中，当多个事务同时读取同一行数据时，MVCC是如何保证每个事务看到的数据版本是一致的？ 5.MVCC如何帮助提高数据库的并发性能？
技术自由圈/原疯狂创客圈
556 4
京东面试：MySQL MVCC是如何实现的？如何通过MVCC实现读已提交、可重复读隔离级别的？
绿水长流*z
|
SQL 关系型数据库 MySQL
MySQL事务日志-Undo Log工作原理分析
事务的持久性是交由Redo Log来保证，原子性则是交由Undo Log来保证。如果事务中的SQL执行到一半出现错误，需要把前面已经执行过的SQL撤销以达到原子性的目的，这个过程也叫做"回滚"，所以Undo Log也叫回滚日志。
绿水长流*z
769 7
MySQL事务日志-Undo Log工作原理分析

热门文章

最新文章

  • 1
    阿里云DTS踩坑经验分享系列｜如何使用DTS进行MySQL->ClickHouse同步
  • 2
    MySQL表连接（内连接、交叉连接、外连接、联合查询）
  • 3
    MySQL 小心使用 replace into
  • 4
    对比MySQL，一文看透HBase的能力及使用场景
  • 5
    mysql存储过程及常用函数
  • 6
    MySQL - 关键字作为列名/表名的处理方式
  • 7
    MySQL的常用操作
  • 8
    rds备份与恢复
  • 9
    MySQL next-key lock 加锁范围总结
  • 10
    mysql5.7数据库用户过期
  • 1
    【紧急救援】MySQL CPU 100%！一套组合拳教你快速定位并解决！
    600
  • 2
    MySQL中日期和时间函数的使用指南
    330
  • 3
    MySQL 与 Redis 如何保证双写一致性？
    581
  • 4
    【赵渝强老师】MySQL的事务隔离级别
    345
  • 5
    【Docker】（3）学习Docker中 镜像与容器数据卷、映射关系！手把手带你安装 MySql主从同步 和 Redis三主三从集群！并且进行主从切换与扩容操作，还有分析 哈希分区 等知识点！
    671
  • 6
    MySQL源码编译安装
    1181
  • 7
    MySQL二进制包安装
    658
  • 8
    MySQL包安装 -- SUSE系列（离线RPM包安装MySQL）
    582
  • 9
    MySQL包安装 -- SUSE系列（SUSE资源库安装MySQL）
    506
  • 10
    MySQL包安装 -- Debian系列（离线DEB包安装MySQL）
    1949

    • 相关课程

    更多
  • MySQL企业常见架构与调优经验分享
  • 阿里云云原生数据仓库AnalyticDB MySQL版 使用教程
  • MySQL实战进阶
  • 阿里云数据库产品家族及特性
  • 数据库及SQL/MySQL基础
  • 云数据库MySQL快速入门

    • 相关电子书

    更多
  • PolarDB MySQL引擎重磅功能及产品能力盛大发布
  • 阿里云MySQL云数据库产品体系介绍
  • One Box： 解读事务与分析一体化数据库 HybridDB for MySQL

    • 推荐镜像

    更多
  • mysql
    • 下一篇
    ECS账号安全防护最佳实践