MySQL事务隔离级别锁机制分析论证

2024-01-21 01:32

本文主要是介绍MySQL事务隔离级别锁机制分析论证,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

基本概念

1、事务隔离级别说明
ANSI/ISO SQL标准定义了4中事务隔离级别:未提交读(read uncommitted),提交读(read committed),重复读(repeatable read),串行读(serializable)。
对于不同的事务,采用不同的隔离级别分别有不同的结果。不同的隔离级别有不同的现象。主要有下面3种现在:
a、脏读(dirty read):一个事务可以读取另一个尚未提交事务的修改数据。
b、不可重复读(nonrepeatable read):在同一个事务中,同一个查询在T1时间读取某一行,在T2时间重新读取这一行时候,这一行的数据已经发生修改,可能被更新了(update),也可能被删除了(delete)。
b、幻像读(phantom read):在同一事务中,同一查询多次进行时候,由于其他插入操作(insert)的事务提交,导致每次返回不同的结果集。
不同的隔离级别有不同的现象,并有不同的锁定/并发机制,隔离级别越高,数据库的并发性就越差,4种事务隔离级别分别表现的现象如下表:
隔离级别 脏读 非重复读 幻像读
read uncommitted 允许 允许 允许
read committed   允许 允许
repeatable read     允许
serializable      

2、锁机制说明:
共享锁:由 表操作加上的锁,加锁后其他用户只能获取该表或行的共享锁,不能获取排它锁,也就是说只能读不能写
排它锁:由 表操作加上的锁,加锁后其他用户不能获取该表或行的任何锁,也可以理解为 表或行锁定。典型是mysql事务中
start transaction;
select * from user where userId = 1 for update ;
执行完这句以后
1)当其他事务想要获取共享锁,比如事务隔离级别为SERIALIZABLE的事务,执行
select * from user;
将会被挂起,因为SERIALIZABLE的select语句需要获取共享锁
  2)当其他事务执行
select * from user where userId = 1 for update;
update user set userAge = 100 where userId = 1; 
也会被挂起,因为for update会获取这一行数据的排它锁,需要等到前一个事务释放该排它锁才可以继续进行
特别注意:如果for update 前的where 并非主键过滤则为表级排它锁,仅有过滤参数为 =ID主键时方为行级排它锁) 

3、锁的范围:
行锁: 对某行记录加上锁
表锁: 对整个表加上锁
这样组合起来就有,行级共享锁,表级共享锁,行级排他锁,表级排他锁

4、悲观锁与悲观锁
悲观锁:显式为数据加锁,常见有如下两种加锁方式 
    1. 显式指定独占锁:select … for update
    2. 在数据库增加表明状态的LOCK字段
乐观锁:通过版本控制实现, 这种方式我们能够更好地提高并发事务的性能。

验证REPEATABLE-READ的实例效果

使用InnoDB,开启两个客户端SESSION1、SESSION2
1、通过SELECT @@GLOBAL.tx_isolation, @@tx_isolation;查看默认的事务隔离级别:

如果我们修改当前session修改其事务隔离级别,可以通过如下方式:


2、REPEATABLE-READ隔离级别验证:
 SESSION1SESSION2
T1mysql> start transaction;
Query OK, 0 rows affected (0.00 sec)
mysql> start transaction;
Query OK, 0 rows affected (0.00 sec)
T2mysql> use icbc;
Database changed
mysql> SELECT amount,fromcard FROM t_eventlog;
+--------+----------+
| amount | fromcard |
+--------+----------+
| 222.00 | card001 |
+--------+----------+
1 row in set (0.11 sec)
mysql> use icbc;
Database changed
mysql> SELECT amount,fromcard FROM t_eventlog;
+--------+----------+
| amount | fromcard |
+--------+----------+
| 222.00 | card001 |
+--------+----------+
1 row in set (0.00 sec)
T3mysql> update t_eventlog set amount=111 where fromcard='card001';
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
 
T4mysql> SELECT amount,fromcard FROM t_eventlog;
+--------+----------+
| amount | fromcard |
+--------+----------+
| 111.00 | card001 |
+--------+----------+
1 row in set (0.00 sec)
【说明】session1能够读取自己修改的最新数据
mysql> SELECT amount,fromcard FROM t_eventlog;
+--------+----------+
| amount | fromcard |
+--------+----------+
| 222.00 | card001 |
+--------+----------+
1 row in set (0.12 sec)
【说明】amount不变,session1中修改数据事务未提交,并未出现脏读
T5 mysql> update t_eventlog set amount=333 where fromcard='card001';
【说明】session2修改直接被挂起,因为session1事务未提交
T6mysql> commit
    -> ;
Query OK, 0 rows affected (0.00 sec)
mysql> update t_eventlog set amount=333 where fromcard='card001';
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
mysql> start transaction;
Query OK, 0 rows affected (0.00 sec)
【说明】session1提交事务,session2本应提交修改,但超时需要重启事务,下面加快速度重复上述T2~T6操作
T2mysql> SELECT amount,fromcard FROM t_eventlog;
+--------+----------+
| amount | fromcard |
+--------+----------+
| 111.00 | card001 |
+--------+----------+
1 row in set (0.00 sec)
mysql> SELECT amount,fromcard FROM t_eventlog;
+--------+----------+
| amount | fromcard |
+--------+----------+
| 111.00 | card001 |
+--------+----------+
1 row in set (0.00 sec)
T3mysql> update t_eventlog set amount=1 where fromcard='card001';
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
 
T4mysql> SELECT amount,fromcard FROM t_eventlog;
+--------+----------+
| amount | fromcard |
+--------+----------+
| 1.00 | card001 |
+--------+----------+
1 row in set (0.00 sec)
【说明】session1能够读取自己修改的最新数据
mysql> SELECT amount,fromcard FROM t_eventlog;
+--------+----------+
| amount | fromcard |
+--------+----------+
| 111.00 | card001 |
+--------+----------+
1 row in set (0.00 sec)
【说明】amount不变,session1中修改数据事务未提交,并未出现脏读
T5 mysql> update t_eventlog set amount=2 where fromcard='card001';
【说明】session2修改直接被挂起,因为session1事务未提交
T6mysql> commit
    -> ;
Query OK, 0 rows affected (0.00 sec)
【说明】提交session1事务
 
T7 Query OK, 1 row affected (4.79 sec)
Rows matched: 1 Changed: 1 Warnings: 0
【说明】session1事务提交,session2执行修改数据
T8mysql> SELECT amount,fromcard FROM t_eventlog;
+--------+----------+
| amount | fromcard |
+--------+----------+
| 1.00 | card001 |
+--------+----------+
1 row in set (0.00 sec)
【说明】amount不变,session2中修改数据事务未提交,并未出现脏读
mysql> SELECT amount,fromcard FROM t_eventlog;
+--------+----------+
| amount | fromcard |
+--------+----------+
| 2.00 | card001 |
+--------+----------+
1 row in set (0.00 sec)
T9 mysql> commit
    -> ;
Query OK, 0 rows affected (0.00 sec)
T10mysql> SELECT amount,fromcard FROM t_eventlog;
+--------+----------+
| amount | fromcard |
+--------+----------+
| 2.00 | card001 |
+--------+----------+
1 row in set (0.00 sec)
【说明】读取到最新的session2提交事务数据
mysql> SELECT amount,fromcard FROM t_eventlog;
+--------+----------+
| amount | fromcard |
+--------+----------+
| 2.00 | card001 |
+--------+----------+
1 row in set (0.00 sec)
T11mysql> show variables like 'autocommit'\G
*************************** 1. row ***************************
Variable_name: autocommit
        Value: ON
1 row in set, 1 warning (0.00 sec)
【说明】在session1中T8、T10两次的数据不一致,是否违背了重复读呢,其实不然,由于我们设置的事务提交是自动。
mysql> show variables like 'autocommit'\G
*************************** 1. row ***************************
Variable_name: autocommit
        Value: ON
1 row in set, 1 warning (0.00 sec)
A以上已经证明了不会出现脏读,只有在更新事务提交后方可被其他事务读取修改后数据;如果两个事务同时对某一数据行进行更新操作,如A事务先更新,则B事务被挂起,待A更新操作事务提交后,B事务执行更新操作并等待事务提交(更新操作可能出现等待超时),提交后最终数据为B事务提交数据。其实是加上了行共享锁,此时数据行能够被多个事务读取却不能被写。
T12mysql> set @@autocommit = 0
    -> ;
Query OK, 0 rows affected (0.00 sec)
【说明】设置事务提交手动
mysql> set @@autocommit = 0
    -> ;
Query OK, 0 rows affected (0.00 sec)
【说明】设置事务提交手动
T13mysql> start transaction;
Query OK, 0 rows affected (0.00 sec)
mysql> start transaction;
Query OK, 0 rows affected (0.00 sec)
T14mysql> SELECT amount,fromcard FROM t_eventlog;
+--------+----------+
| amount | fromcard |
+--------+----------+
| 2.00 | card001 |
+--------+----------+
1 row in set (0.00 sec)
mysql> SELECT amount,fromcard FROM t_eventlog;
+--------+----------+
| amount | fromcard |
+--------+----------+
| 2.00 | card001 |
+--------+----------+
1 row in set (0.00 sec)
T15 mysql> update t_eventlog set amount=3 where fromcard='card001';
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
T16mysql> SELECT amount,fromcard FROM t_eventlog;
+--------+----------+
| amount | fromcard |
+--------+----------+
| 2.00 | card001 |
+--------+----------+
1 row in set (0.00 sec)
 
T17 mysql> commit
    -> ;
Query OK, 0 rows affected (0.00 sec)

mysql> SELECT amount,fromcard FROM t_eventlog;
+--------+----------+
| amount | fromcard |
+--------+----------+
| 3.00 | card001 |
+--------+----------+
1 row in set (0.00 sec)
【说明】提交事务后查询为最新提交的事务数据
T18mysql> SELECT amount,fromcard FROM t_eventlog;
+--------+----------+
| amount | fromcard |
+--------+----------+
| 2.00 | card001 |
+--------+----------+
1 row in set (0.00 sec)
【说明】数据依然没有变化,目前为手动提交事务,查询也需要手动提交。此时说明在一个事务内重复读,数据是一致的。
 
T19mysql> commit
    -> ;
Query OK, 0 rows affected (0.00 sec)

mysql> SELECT amount,fromcard FROM t_eventlog;
+--------+----------+
| amount | fromcard |
+--------+----------+
| 3.00 | card001 |
+--------+----------+
1 row in set (0.00 sec)
【说明】session1提交查看事务后重新查询,可以看到session2提交的最新的数据
 
B通过手动提交事务验证了,REPEATABLE-READ级别隔离下,在一个事务内,我们多次查询结果是一样的,能够重复读。
以上的验证过程主要是针对共享锁实现。

综上
1、我们在REPEATABLE-READ级别隔离下,如果多个事务同时操作一个数据行,则后执行更新操作的事务将被挂起,直到第一个更新事务提交后,后执行事务将继续执行(可能出现挂起直到超时)其更新动作,待最后执行事务也提交后,数据库将保存最后一个事务的更新结果。此过程中,事务间互不干扰,只有提交事务后的数据方可被其他事务读取(避免了脏读),并且在同一事务下,多次读取的数据将保持一致,实现重复读;
2、mysql有一个autocommit参数,默认是on,他的作用是每一条单独的查询都是一个事务,并且自动开始,自动提交(执行完以后就自动结束了,如果要适用select for update,而不手动调用 start transaction,这个for update的行锁机制等于没用,因为行锁在自动提交后就释放了),所以事务隔离级别和锁机制即使不显式调用start transaction,这种机制在单独的一条查询语句中也是适用的;
3、其实无乱是哪个级别的隔离,甚至最低级别在一个事务(A)更新修改后,其他事务在A事务提交前均被挂起,仅A事务提交后方可进行数据行更新处理(可能超时),其均是由于A事务对其添加了 行共享锁
4、这里虽然没有继续验证,但如果采用SERIALIZABLE级别的隔离,则其查询|更新任意操作后均会对其添加 表共享锁,从而其他事务 仅可以读操作,不能执行任何写操作

这篇关于MySQL事务隔离级别锁机制分析论证的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/627976

相关文章

JVM 的类初始化机制

前言 当你在 Java 程序中new对象时,有没有考虑过 JVM 是如何把静态的字节码(byte code)转化为运行时对象的呢,这个问题看似简单,但清楚的同学相信也不会太多,这篇文章首先介绍 JVM 类初始化的机制,然后给出几个易出错的实例来分析,帮助大家更好理解这个知识点。 JVM 将字节码转化为运行时对象分为三个阶段,分别是:loading 、Linking、initialization

SQL中的外键约束

外键约束用于表示两张表中的指标连接关系。外键约束的作用主要有以下三点: 1.确保子表中的某个字段(外键)只能引用父表中的有效记录2.主表中的列被删除时,子表中的关联列也会被删除3.主表中的列更新时,子表中的关联元素也会被更新 子表中的元素指向主表 以下是一个外键约束的实例展示

基于MySQL Binlog的Elasticsearch数据同步实践

一、为什么要做 随着马蜂窝的逐渐发展,我们的业务数据越来越多,单纯使用 MySQL 已经不能满足我们的数据查询需求,例如对于商品、订单等数据的多维度检索。 使用 Elasticsearch 存储业务数据可以很好的解决我们业务中的搜索需求。而数据进行异构存储后,随之而来的就是数据同步的问题。 二、现有方法及问题 对于数据同步,我们目前的解决方案是建立数据中间表。把需要检索的业务数据,统一放到一张M

如何去写一手好SQL

MySQL性能 最大数据量 抛开数据量和并发数,谈性能都是耍流氓。MySQL没有限制单表最大记录数,它取决于操作系统对文件大小的限制。 《阿里巴巴Java开发手册》提出单表行数超过500万行或者单表容量超过2GB,才推荐分库分表。性能由综合因素决定,抛开业务复杂度,影响程度依次是硬件配置、MySQL配置、数据表设计、索引优化。500万这个值仅供参考,并非铁律。 博主曾经操作过超过4亿行数据

性能分析之MySQL索引实战案例

文章目录 一、前言二、准备三、MySQL索引优化四、MySQL 索引知识回顾五、总结 一、前言 在上一讲性能工具之 JProfiler 简单登录案例分析实战中已经发现SQL没有建立索引问题,本文将一起从代码层去分析为什么没有建立索引? 开源ERP项目地址:https://gitee.com/jishenghua/JSH_ERP 二、准备 打开IDEA找到登录请求资源路径位置

MySQL数据库宕机,启动不起来,教你一招搞定!

作者介绍:老苏,10余年DBA工作运维经验,擅长Oracle、MySQL、PG、Mongodb数据库运维(如安装迁移,性能优化、故障应急处理等)公众号:老苏畅谈运维欢迎关注本人公众号,更多精彩与您分享。 MySQL数据库宕机,数据页损坏问题,启动不起来,该如何排查和解决,本文将为你说明具体的排查过程。 查看MySQL error日志 查看 MySQL error日志,排查哪个表(表空间

MySQL高性能优化规范

前言:      笔者最近上班途中突然想丰富下自己的数据库优化技能。于是在查阅了多篇文章后,总结出了这篇! 数据库命令规范 所有数据库对象名称必须使用小写字母并用下划线分割 所有数据库对象名称禁止使用mysql保留关键字(如果表名中包含关键字查询时,需要将其用单引号括起来) 数据库对象的命名要能做到见名识意,并且最后不要超过32个字符 临时库表必须以tmp_为前缀并以日期为后缀,备份

[MySQL表的增删改查-进阶]

🌈个人主页:努力学编程’ ⛅个人推荐: c语言从初阶到进阶 JavaEE详解 数据结构 ⚡学好数据结构,刷题刻不容缓:点击一起刷题 🌙心灵鸡汤:总有人要赢,为什么不能是我呢 💻💻💻数据库约束 🔭🔭🔭约束类型 not null: 指示某列不能存储 NULL 值unique: 保证某列的每行必须有唯一的值default: 规定没有给列赋值时的默认值.primary key:

Java ArrayList扩容机制 (源码解读)

结论:初始长度为10,若所需长度小于1.5倍原长度,则按照1.5倍扩容。若不够用则按照所需长度扩容。 一. 明确类内部重要变量含义         1:数组默认长度         2:这是一个共享的空数组实例,用于明确创建长度为0时的ArrayList ,比如通过 new ArrayList<>(0),ArrayList 内部的数组 elementData 会指向这个 EMPTY_EL

SWAP作物生长模型安装教程、数据制备、敏感性分析、气候变化影响、R模型敏感性分析与贝叶斯优化、Fortran源代码分析、气候数据降尺度与变化影响分析

查看原文>>>全流程SWAP农业模型数据制备、敏感性分析及气候变化影响实践技术应用 SWAP模型是由荷兰瓦赫宁根大学开发的先进农作物模型,它综合考虑了土壤-水分-大气以及植被间的相互作用;是一种描述作物生长过程的一种机理性作物生长模型。它不但运用Richard方程,使其能够精确的模拟土壤中水分的运动,而且耦合了WOFOST作物模型使作物的生长描述更为科学。 本文让更多的科研人员和农业工作者