实例分析MySQL下的四种事务隔离级别

数据库事务有四种隔离级别:

  • 未提交读(Read Uncommitted):允许脏读,也就是可能读取到其他会话中未提交事务修改的数据。
  • 提交读(Read Committed):只能读取到已经提交的数据,Oracle等多数数据库默认都是该级别。
  • 可重复读(Repeated Read):可重复读。在同一个事务内的查询都是事务开始时刻一致的,InnoDB默认级别。在SQL标准中,该隔离级别消除了不可重复读,但是还存在幻读。
  • 串行读(Serializable):完全串行化的读,每次读都需要获得表级共享锁,读写相互都会阻塞。

上面这样的教科书式定义***次接触事务隔离概念的朋友看了可能会一脸懵逼,下面我们就通过具体的实例来解释四个隔离级别。

首先我们创建一个user表:

  1. CREATE TABLE user ( 
  2.     `id` int(11) NOT NULL AUTO_INCREMENT, 
  3.     `namevarchar(255) NOT NULL
  4.     PRIMARY KEY (`id`), 
  5.     UNIQUE `uniq_name` USING BTREE (name
  6. ) ENGINE=`InnoDB` AUTO_INCREMENT=10 DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci; 

 

读未提交隔离级别

我们先将事务的隔离级别设置为read committed:

  1. mysql> set session transaction isolation level read uncommitted
  2. Query OK, 0 rows affected (0.00 sec) 
  3.  
  4. mysql> select @@session.tx_isolation; 
  5. +------------------------+ 
  6. | @@session.tx_isolation | 
  7. +------------------------+ 
  8. READ-UNCOMMITTED       | 
  9. +------------------------+ 
  10. 1 row in set (0.00 sec) 

 

在下面我们开了两个终端分别用来模拟事务一和事务二,p.s: 操作一和操作二的意思是按照时间顺序来执行的。

事务1

  1. mysql> start transaction; # 操作1 
  2.  
  3. Query OK, 0 rows affected (0.00 sec) 
  4.  
  5. mysql> insert into user(namevalues('ziwenxie'); # 操作3 
  6.  
  7. Query OK, 1 row affected (0.05 sec) 

 

事务2

  1. mysql> start transaction; # 操作2 
  2.  
  3. Query OK, 0 rows affected (0.00 sec) 
  4.  
  5. mysql> select * from user; # 操作4 
  6.  
  7. +----+----------+ 
  8.  
  9. | id | name | 
  10.  
  11. +----+----------+ 
  12.  
  13. | 10 | ziwenxie | 
  14.  
  15. +----+----------+ 
  16.  
  17. 1 row in set (0.00 sec) 

 

从上面的执行结果可以和清晰的看出来,在read uncommited级别下面我们在事务一中可能会读取到事务二中没有commit的数据,这就是脏读。

读提交隔离级别

通过设置隔离级别为committed可以解决上面的脏读问题。

  1. mysql> set session transaction isolation level read committed

事务一

  1. mysql> start transaction; # 操作一 
  2.  
  3. Query OK, 0 rows affected (0.00 sec) 
  4.  
  5. mysql> select * from user; # 操作三 
  6.  
  7. +----+----------+ 
  8.  
  9. | id | name | 
  10.  
  11. +----+----------+ 
  12.  
  13. | 10 | ziwenxie | 
  14.  
  15. +----+----------+ 
  16.  
  17. 1 row in set (0.00 sec) 
  18.  
  19. mysql> select * from user; # 操作五,操作四的修改并没有影响到事务一 
  20.  
  21. +----+----------+ 
  22.  
  23. | id | name | 
  24.  
  25. +----+----------+ 
  26.  
  27. | 10 | ziwenxie | 
  28.  
  29. +----+----------+ 
  30.  
  31. 1 row in set (0.00 sec) 
  32.  
  33. mysql> select * from user; # 操作七 
  34.  
  35. +----+------+ 
  36.  
  37. | id | name | 
  38.  
  39. +----+------+ 
  40.  
  41. | 10 | lisi | 
  42.  
  43. +----+------+ 
  44.  
  45. 1 row in set (0.00 sec) 
  46.  
  47. mysql> commit; # 操作八 
  48.  
  49. Query OK, 0 rows affected (0.00 sec) 

 

事务二

  1. mysql> start transaction; # 操作二 
  2.  
  3. Query OK, 0 rows affected (0.00 sec) 
  4.  
  5. mysql> update user set name='lisi' where id=10; # 操作四 
  6.  
  7. Query OK, 1 row affected (0.06 sec) 
  8.  
  9. Rows matched: 1 Changed: 1 Warnings: 0 
  10.  
  11. mysql> commit; # 操作六 
  12.  
  13. Query OK, 0 rows affected (0.08 sec) 

 

虽然脏读的问题解决了,但是注意在事务一的操作七中,事务二在操作六commit后会造成事务一在同一个transaction中两次读取到的数据不同,这就是不可重复读问题,使用第三个事务隔离级别repeatable read可以解决这个问题。

可重复读隔离级别

MySQL的Innodb存储引擎默认的事务隔离级别就是可重复读隔离级别,所以我们不用进行多余的设置。

事务一

  1. mysql> start tansactoin; # 操作一 
  2.  
  3. mysql> select * from user; # 操作五 
  4.  
  5. +----+----------+ 
  6.  
  7. | id | name | 
  8.  
  9. +----+----------+ 
  10.  
  11. | 10 | ziwenxie | 
  12.  
  13. +----+----------+ 
  14.  
  15. 1 row in set (0.00 sec) 
  16.  
  17. mysql> commit; # 操作六 
  18.  
  19. Query OK, 0 rows affected (0.00 sec) 
  20.  
  21. mysql> select * from user; # 操作七 
  22.  
  23. +----+------+ 
  24.  
  25. | id | name | 
  26.  
  27. +----+------+ 
  28.  
  29. | 10 | lisi | 
  30.  
  31. +----+------+ 
  32.  
  33. 1 row in set (0.00 sec) 

 

事务二

  1. mysql> start tansactoin; # 操作二 
  2.  
  3. mysql> update user set name='lisi' where id=10; # 操作三 
  4.  
  5. Query OK, 1 row affected (0.00 sec) 
  6.  
  7. Rows matched: 1 Changed: 1 Warnings: 0 
  8.  
  9. mysql> commit; # 操作四 

 

在事务一的操作五中我们并没有读取到事务二在操作三中的update,只有在commit之后才能读到更新后的数据。

Innodb解决了幻读么

实际上RR级别是可能产生幻读,InnoDB引擎官方称中利用MVCC多版本并发控制解决了这个问题,下面我们验证一下Innodb真的解决了幻读了么?

为了方便展示,我修改了一下上面的user表:

  1. mysql> alter table user add salary int(11); 
  2.  
  3. Query OK, 0 rows affected (0.51 sec) 
  4.  
  5. Records: 0 Duplicates: 0 Warnings: 0 
  6.  
  7. mysql> delete from user
  8.  
  9. Query OK, 1 rows affected (0.07 sec) 
  10.  
  11. mysql> insert into user(name, salary) value('ziwenxie', 88888888); 
  12.  
  13. Query OK, 1 row affected (0.07 sec) 
  14.  
  15. mysql> select * from user
  16.  
  17. +----+----------+----------+ 
  18.  
  19. | id | name | salary | 
  20.  
  21. +----+----------+----------+ 
  22.  
  23. | 10 | ziwenxie | 88888888 | 
  24.  
  25. +----+----------+----------+ 
  26.  
  27. 1 row in set (0.00 sec) 

 

事务一

  1. mysql> start transaction; # 操作一 
  2.  
  3. Query OK, 0 rows affected (0.00 sec) 
  4.  
  5. mysql> update user set salary='4444'; # 操作六,竟然影响了两行,不是说解决了幻读么? 
  6.  
  7. Query OK, 2 rows affected (0.00 sec) 
  8.  
  9. Rows matched: 2 Changed: 2 Warnings: 0 
  10.  
  11. mysql> select * from user; # 操作七, Innodb并没有完全解决幻读 
  12.  
  13. +----+----------+--------+ 
  14.  
  15. | id | name | salary | 
  16.  
  17. +----+----------+--------+ 
  18.  
  19. | 10 | ziwenxie | 4444 | 
  20.  
  21. | 11 | zhangsan | 4444 | 
  22.  
  23. +----+----------+--------+ 
  24.  
  25. rows in set (0.00 sec) 
  26.  
  27. mysql> commit; # 操作八 
  28.  
  29. Query OK, 0 rows affected (0.04 sec) 

 

事务二

  1. mysql> start transaction; # 操作二 
  2.  
  3. Query OK, 0 rows affected (0.00 sec) 
  4.  
  5. mysql> insert into user(name, salary) value('zhangsan''666666'); # 操作四 
  6.  
  7. Query OK, 1 row affected (0.00 sec) 
  8.  
  9. mysql> commit; # 操作五 
  10.  
  11. Query OK, 0 rows affected (0.04 sec) 

 

从上面的例子可以看出,Innodb并没有如官方所说解决幻读,不过上面这样的场景中也不是很常见不用过多的担心。

串行化隔离级别

所有事务串行执行,***隔离级别,不会出现幻读性能会很差,实际开发中很少使用到。 

文章来源网络,作者:管理,如若转载,请注明出处:https://shuyeidc.com/wp/269840.html<

(0)
管理的头像管理
上一篇2025-05-07 13:12
下一篇 2025-05-07 13:13

相关推荐

  • 站群服务器和普通服务器到底哪个更适合GEO,怎么选?

    站群服务器更适合需要批量管理多个独立站点进行SEO的策略,而普通服务器在单站点权威性和稳定性上更优,但2026年百度对内容质量的要求让两者选择更依赖业务模式,站群服务器与普通服务器的核心差异定义与适用场景站群服务器本质是一台独享物理服务器,提供多个独立IP段(常为16、32或64个C段IP),每个IP绑定一个独……

    2026-07-28
    0
  • 物理服务器和云服务器做站群到底选哪个,哪个更稳定?

    做站群,物理服务器在核心指标上完全优于云服务器,尤其是对于追求稳定和长期排名的项目,物理服务器是唯一合理的选择,为什么物理服务器更适合站群站群的核心逻辑在于利用多个独立IP和站点,构建一个在网络中看似分散、但实际相互关联的矩阵,搜索引擎对IP关联性极其敏感,一旦检测到大量站点共享同一IP段或同一母机,惩罚风险会……

    2026-07-28
    0
  • 国内高防服务器哪家防御真实靠谱,怎么选?

    国内高防服务器哪家防御真实靠谱?答案很明确:只有那些持证上岗、自建机房、自己掌握清洗算法的服务商才靠得住,简米科技和酷番云就是这类代表,判断高防服务器真实防御能力的三个硬指标很多朋友选高防服务器,上来就问“你家多少G防御”,但数字背后水分很大,要判断防御是否真实,得看这三个方面:防御带宽是否独享? 有些服务商宣……

    2026-07-28
    0
  • 裸金属服务器和物理服务器有什么区别?,怎么选?

    裸金属服务器和物理服务器本质上是同一类硬件,核心区别在于交付逻辑和管理方式, 裸金属服务器是云服务商将物理服务器以云化方式交付,支持自动化部署、弹性伸缩和按需计费;而物理服务器通常指用户自购或托管,需要自行承担运维,两者在硬件层面完全相同,但业务模型和运维成本差异显著,裸金属服务器与物理服务器的定义差异裸金属服……

    2026-07-28
    0
  • 做GEO站群选哪家服务器服务商靠谱,怎么选?

    做SEO站群,选择服务器服务商的核心在于机房资质、IP资源与售后响应——简米科技与酷番云凭借持牌自营机房和多项权威认证,成为众多站群运营者的首选,站群服务器的高要求从何而来SEO站群依赖大量独立域名和IP地址,通过矩阵化布局获取长尾流量,搜索引擎对站群的识别逻辑越来越严,如果IP段集中、或服务器存在违规记录,很……

    2026-07-28
    0

发表回复

您的邮箱地址不会被公开。必填项已用 * 标注