如何理解MySQL事务的隔离级别(mydql事务隔离级别)
mhr18 2024-09-18 20:23 17 浏览 0 评论
如何理解MySQL事务的隔离级别
- 读未提交(READ UNCOMMITTED)
- 读已提交(READ COMMITTED)
- 可重复读(REPEATABLE READ)
- 可串行化(SERIALIZABLE)
- MySQL的默认事务的隔离级别是可重复读
-- 登录mysql的root账户,-p待输入密码,-h mysql服务器地址 -P 端口号(注意大写)
? mysql -u root -p -h localhost -P 3307
Enter password: ****
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 284
Server version: 5.7.28 MySQL Community Server (GPL)
Copyright (c) 2000, 2019, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql>
-- 查看当前事务的隔离级别
mysql> show variables like 'transaction_isolation';
+-----------------------+-----------------+
| Variable_name | Value |
+-----------------------+-----------------+
| transaction_isolation | REPEATABLE-READ |
+-----------------------+-----------------+
-- 或者如此查看事务的隔离级别
mysql> SELECT @@transaction_isolation;
+-------------------------+
| @@transaction_isolation |
+-------------------------+
| REPEATABLE-READ |
+-------------------------+
-- 可以看到MySQL的默认事务隔离级别是可重复读
读未提交
会产生所有的问题(脏读、不可重复读、幻读)
读已提交
在此事务隔离级别下,事务B只能在事务A修改并且已提交后才能读取到事务A修改的数据。
避免了脏读
但还是会产生(不可重复读、幻读)
可重复读
在此事务隔离级别下,事务B只能在事务A修改数据并提交后,自己也提交事务后,才能读取到事务A修改的数据。
避免了脏读和不可重复读
但还是会产生幻读问题
可串行化
此种事务隔离级别别最高,不会发生任何以下问题(脏读、可重复读、幻读),通过加锁实现
读锁和写锁,只在读读不阻塞,读写、写读、写写都会阻塞。
解读一下并发造成的问题(脏读、不可重复读、幻读)
数据库表t_user我的表字段
mysql> show columns from t_user;
+-------+-------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+-------+-------------+------+-----+---------+----------------+
| id | int(11) | NO | PRI | NULL | auto_increment |
| name | varchar(50) | NO | | NULL | |
+-------+-------------+------+-----+---------+----------------+
注意:MySQL 默认开启事务自动提交模式,即除非显式的开启事务(BEGIN 或 START TRANSACTION),否则每条 SOL 语句都会被当做一个单独的事务自动执行。
-- 可以看到mysql默认开启自动提交模式
mysql> SHOW VARIABLES LIKE 'autocommit';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| autocommit | ON |
+---------------+-------+
-- 可以设置是否自动提交
-- 值为 0 和值为 OFF:关闭事务自动提交。
-- 值为 1 和值为 ON:开启事务自动提交。
-- 如下可设置的4种值
-- SET autocommit = 0|1|ON|OFF;
- 脏读
事务A 读取到了 事务B 修改但是未提交的脏数据
开始之前一定调整事务的隔离级别为读未提交,不然不可能产生脏读现象
mysql> SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
Query OK, 0 rows affected (0.00 sec)
mysql> SELECT @@transaction_isolation;
+-------------------------+
| @@transaction_isolation |
+-------------------------+
| READ-UNCOMMITTED |
+-------------------------+
首先查看一下t_user表的数据
mysql> select * from t_user;
+----+--------+
| id | name |
+----+--------+
| 1 | 达摩 |
+----+--------+
然后进行如下测试
-- session1 事务A 开始
mysql> begin;
-- session2 事务B 开始
mysql> begin;
-- session2 事务B 修改name = 吕布 (注意这里并未提交)
mysql> update t_user set name = '吕布' where id = 1;
-- session1 事务A 读取id = 1的数据 (注意,读到了未提交的脏数据 name = 吕布)
mysql> select * from t_user where id = 1;
+----+--------+
| id | name |
+----+--------+
| 1 | 吕布 |
+----+--------+
-- session1 事务A 对读到的脏数据进行提交(事务A结束)
mysql> commit;
-- session2 事务B 对刚才的修改进行回滚(事务B结束)
mysql> rollback;
-- 最终数据库中的name并没有改变,但是事务A读到了脏数据,这就是脏读
-- 此事务隔离级别(读未提交)也会造成不可重复读和幻读,这里不做演示,看下面的隔离级别中演示
- 不可重复读
事务A 读取表的名字为达摩(并未提交),之后事务B修改了名字为曹操(修改完提交了),此时事务A在未提交的情况下又读取了name却变成了曹操,这就是不可重复读
设置事务的隔离级别为读已提交,也可以为读未提交,因为读未提交也会产生不可重复读现象
-- 设置事务的隔离级别为读已提交
mysql> SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
Query OK, 0 rows affected (0.00 sec)
-- 查看修改结果,已经为读已提交
mysql> SELECT @@transaction_isolation;
+-------------------------+
| @@transaction_isolation |
+-------------------------+
| READ-COMMITTED |
+-------------------------+
首先查看一下t_user表的数据
mysql> select * from t_user;
+----+--------+
| id | name |
+----+--------+
| 1 | 达摩 |
+----+--------+
然后进行如下测试
-- session1 事务A开始事务
mysql> begin;
Query OK, 0 rows affected (0.00 sec)
-- session1 事务A 读取表中数据(注意此时未提交事务)
mysql> select * from t_user where id = 1;
+----+--------+
| id | name |
+----+--------+
| 1 | 达摩 |
+----+--------+
-- session2 事务B直接修改并提交事务
mysql> update t_user set name = '曹操' where id = 1;
Query OK, 1 row affected (0.03 sec)
-- session1 事务A 再次读取表中数据,发现同一个事务中得到了不一样的结果,这就是不可重复读
mysql> select * from t_user where id = 1;
+----+--------+
| id | name |
+----+--------+
| 1 | 曹操 |
+----+--------+
-- 只要是事务A一直不提交,其他事务修改提交之后,事务A再次查询都能查到最新修改的结果
-- 此事务隔离级别也会造成幻读,但是避免了脏读
-- 测试是否避免脏读,事务A此时未提交
-- session2 事务B开始
mysql> begin;
Query OK, 0 rows affected (0.00 sec)
-- session2 事务B修改name = 伽罗 (注意此时未提交)
mysql> update t_user set name = '伽罗' where id = 1;
Query OK, 1 row affected (0.00 sec)
-- session1 事务A进行读取,看到并没有读取到脏数据
mysql> select * from t_user where id = 1;
+----+--------+
| id | name |
+----+--------+
| 1 | 曹操 |
+----+--------+
-- session2 事务B回滚
mysql> rollback;
Query OK, 0 rows affected (0.05 sec)
-- session1 事务A提交
mysql> commit;
Query OK, 0 rows affected (0.00 sec)
- 知识点:为什么加了写锁,别的事务还可以进行读操作?
- 因为InnoDB有MVCC机制(多版本并发控制),可以使用快照读,而不会被阻塞。
- 幻读
事务A读取表中数据为一条(这时候未提交), 事务B向表中添加了一条记录(提交),此时事务A再次查询表中数据,结果是两条,好像产生了幻觉,这就是幻读
设置事务的隔离级别为可重复读,也可以为读未提交,也可以为读已提交,因为这三种事务隔离级别都会产生幻读现象
-- 设置事务的隔离级别为可重复读
mysql> SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;
Query OK, 0 rows affected (0.00 sec)
-- 查看修改结果,已经为可重复读
mysql> SELECT @@transaction_isolation;
+-------------------------+
| @@transaction_isolation |
+-------------------------+
| REPEATABLE-READ |
+-------------------------+
首先查看一下t_user表的数据
mysql> select * from t_user;
+----+--------+
| id | name |
+----+--------+
| 1 | 曹操 |
+----+--------+
之后进行的测试
-- session1 事务A开启
mysql> begin;
Query OK, 0 rows affected (0.00 sec)
-- session1 事务A查询(注意未提交)
mysql> select * from t_user;
+----+--------+
| id | name |
+----+--------+
| 1 | 曹操 |
+----+--------+
-- session2 事务B添加数据(提交)
mysql> insert into t_user(name) values('马可波罗');
Query OK, 1 row affected (0.04 sec)
-- session1 事务A再次查询(一个事务中两次查询多出了数据,幻读)
mysql> select * from t_user;
+----+--------------+
| id | name |
+----+--------------+
| 1 | 曹操 |
| 2 | 马可波罗 |
+----+--------------+
-- 测试此事务隔离级别能避免不可重复读现象(此时事务A还是未提交)
-- session2 事务B修改id= 1的数据名字为狄仁杰(提交)
mysql> update t_user set name = '狄仁杰' where id = 1;
Query OK, 1 row affected (0.04 sec)
-- 此时session1 事务A再次读取数据(可以看到跟上一次一样,证明避免了不可重复读现象)
mysql> select * from t_user;
+----+--------------+
| id | name |
+----+--------------+
| 1 | 曹操 |
| 2 | 马可波罗 |
+----+--------------+
以上讲的都是并发操作可能造成的读的问题
相关推荐
- Redis合集-使用benchmark性能测试
-
采用开源Redis的redis-benchmark工具进行压测,它是Redis官方的性能测试工具,可以有效地测试Redis服务的性能。本次测试使用Redis官方最新的代码进行编译,详情请参见Redis...
- Java简历总被已读不回?面试挂到怀疑人生?这几点你可能真没做好
-
最近看了几十份简历,发现大部分人不是技术差,而是不会“卖自己”——一、简历死穴:你写的不是经验,是岗位说明书!反面教材:ד使用SpringBoot开发项目”ד负责用户模块功能实现”救命写法:...
- redission YYDS(redission官网)
-
每天分享一个架构知识Redission是一个基于Redis的分布式Java锁框架,它提供了各种锁实现,包括可重入锁、公平锁、读写锁等。使用Redission可以方便地实现分布式锁。red...
- 从数据库行锁到分布式事务:电商库存防超卖的九重劫难与破局之道
-
2023年6月18日我们维护的电商平台在零点刚过3秒就遭遇了严重事故。监控大屏显示某爆款手机SKU_IPHONE13_PRO_MAX在库存仅剩500台时,订单系统却产生了1200笔有效订单。事故复盘发...
- SpringBoot系列——实战11:接口幂等性的形而上思...
-
欢迎关注、点赞、收藏。幂等性不仅是一种技术需求,更是数字文明对确定性追求的体现。在充满不确定性的网络世界中,它为我们建立起可依赖的存在秩序,这或许正是技术哲学最深刻的价值所在。幂等性的本质困境在支付系...
- 如何优化系统架构设计缓解流量压力提升并发性能?Java实战分享
-
如何优化系统架构设计缓解流量压力提升并发性能?Java实战分享在高流量场景下。首先,我需要回忆一下常见的优化策略,比如负载均衡、缓存、数据库优化、微服务拆分这些。不过,可能还需要考虑用户的具体情况,比...
- Java面试题: 项目开发中的有哪些成长?该如何回答
-
在Java面试中,当被问到“项目中的成长点”时,面试官不仅想了解你的技术能力,更希望看到你的问题解决能力、学习迭代意识以及对项目的深度思考。以下是回答的策略和示例,帮助你清晰、有说服力地展示成长点:一...
- 互联网大厂后端必看!Spring Boot 如何实现高并发抢券逻辑?
-
你有没有遇到过这样的情况?在电商大促时,系统上线了抢券活动,结果活动刚一开始,服务器就不堪重负,出现超卖、系统崩溃等问题。又或者用户疯狂点击抢券按钮,最后却被告知无券可抢,体验极差。作为互联网大厂的后...
- 每日一题 |10W QPS高并发限流方案设计(含真实代码)
-
面试场景还原面试官:“如果系统要承载10WQPS的高并发流量,你会如何设计限流方案?”你:“(稳住,我要从限流算法到分布式架构全盘分析)…”一、为什么需要限流?核心矛盾:系统资源(CPU/内存/数据...
- Java面试题:服务雪崩如何解决?90%人栽了
-
服务雪崩是指微服务架构中,由于某个服务出现故障,导致故障在服务之间不断传递和扩散,最终造成整个系统崩溃的现象。以下是一些解决服务雪崩问题的常见方法:限流限制请求速率:通过限流算法(如令牌桶算法、漏桶算...
- 面试题官:高并发经验有吗,并发量多少,如何回复?
-
一、有实际高并发经验(建议结构)直接量化"在XX项目中,系统日活用户约XX万,核心接口峰值QPS达到XX,TPS处理能力为XX/秒。通过压力测试验证过XX并发线程下的稳定性。"技术方案...
- 瞬时流量高并发“保命指南”:这样做系统稳如泰山,老板跪求加薪
-
“系统崩了,用户骂了,年终奖飞了!”——这是多少程序员在瞬时大流量下的真实噩梦?双11秒杀、春运抢票、直播带货……每秒百万请求的冲击,你的代码扛得住吗?2025年了,为什么你的系统一遇高并发就“躺平”...
- 其实很多Java工程师不是能力不够,是没找到展示自己的正确姿势。
-
其实很多Java工程师不是能力不够,是没找到展示自己的正确姿势。比如上周有个小伙伴找我,五年经验但简历全是'参与系统设计''优化接口性能'这种空话。我就问他:你做的秒杀...
- PHP技能评测(php等级考试)
-
公司出了一些自我评测的PHP题目,现将题目和答案记录于此,以方便记忆。1.魔术函数有哪些,分别在什么时候调用?__construct(),类的构造函数__destruct(),类的析构函数__cal...
- 你的简历在HR眼里是青铜还是王者?
-
你的简历在HR眼里是青铜还是王者?兄弟,简历投了100份没反应?面试总在第三轮被刷?别急着怀疑人生,你可能只是踩了这些"隐形求职雷"。帮3630+程序员改简历+面试指导和处理空窗期时间...
你 发表评论:
欢迎- 一周热门
- 最近发表
- 标签列表
-
- oracle位图索引 (63)
- oracle批量插入数据 (62)
- oracle事务隔离级别 (53)
- oracle 空为0 (50)
- oracle主从同步 (55)
- oracle 乐观锁 (51)
- redis 命令 (78)
- php redis (88)
- redis 存储 (66)
- redis 锁 (69)
- 启动 redis (66)
- redis 时间 (56)
- redis 删除 (67)
- redis内存 (57)
- redis并发 (52)
- redis 主从 (69)
- redis 订阅 (51)
- redis 登录 (54)
- redis 面试 (58)
- 阿里 redis (59)
- redis 搭建 (53)
- redis的缓存 (55)
- lua redis (58)
- redis 连接池 (61)
- redis 限流 (51)