我们自己通过Sql语句模拟场景来验证Mysql InnoDB引擎事务各级隔离级别对应封锁协议的工作机制。在开始实践之前我们需要做一些准备工作。

准备工作

①准备测试表和测试数据

需要建立一个测试数据表,建表语句:

create table users
(
id int auto_increment not null primary key,
name char(10) not null,
state int not null
);

然后插入一条测试数据:

insert into users values(1,'swj',0);

②关闭数据库事务自动提交

# 0为关闭 1为开启
SET autocommit = 0;

设置完成后我们可以通过下列语句查看是否关闭了自动提交。

show variables like 'autocommit';

OFF关闭无误。

③设置InnoDB存储引擎隔离级别

首先我们可以使用下面的语句分别查看数据库的系统级隔离级别和会话级隔离级别。

select @@global.tx_isolation,@@tx_isolation;



这也说明了MySql数据库默认使用的隔离级别是可重复读(REPEATABLE-READ)

我们可以使用下面的语句设置隔离级别。隔离级别有READ UNCOMMITTED | **READ COMMITTED **| REPEATABLE READ | SERIALIZABLE四种。

SET [SESSION | GLOBAL] TRANSACTION ISOLATION LEVEL {READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIALIZABLE}

[READ UNCOMMITTED]

首先设置数据库隔离级别为读未提交(READ UNCOMMITTED):

set global transaction isolation level READ UNCOMMITTED ;
set session transaction isolation level READ UNCOMMITTED ;

[READ UNCOMMITTED]能解决的问题

我们来看一下为什么[READ UNCOMMITTED]能解决丢失更新的问题:

事务1

START TRANSACTION;
① UPDATE users SET state=state+1 WHERE id=1;
② SELECT sleep(10);
COMMIT;

事务2

START TRANSACTION;
① UPDATE users SET state=state+1 WHERE id=1;
COMMIT;

事务1先于事务2执行。

事务1的执行信息

[SQL 1]START TRANSACTION;
受影响的行: 0
时间: 0.000s [SQL 2]
UPDATE users SET state=state+1 WHERE id=1;
受影响的行: 1
时间: 0.001s [SQL 3]
SELECT sleep(10);
受影响的行: 0
时间: 10.000s [SQL 4]
COMMIT;
受影响的行: 0
时间: 0.068s

事务2的执行信息

[SQL 1]START TRANSACTION;
受影响的行: 0
时间: 0.000s [SQL 2]
UPDATE users SET state=state+1 WHERE id=1;
受影响的行: 1
时间: 8.787s [SQL 3]
COMMIT;
受影响的行: 0
时间: 0.098s

执行结果



结论:读未提交[READ UNCOMMITTED]隔离级别可以解决丢失更新的问题。

分析:因为读未提交[READ UNCOMMITTED]隔离级别对应数据库的一级封锁协议。一级封锁协议在修改数据之前对其加X锁,直到事务结束释放X锁。读数据不加锁。因为事务1先执行修改,修改前申请持有X锁,事务结束释放X锁。持锁时间段为[SQL 2]开始前到[SQL 4]结束,持锁时间大约为10.069s。事务2也执行修改操作,修改前也申请持有X锁。因为事务1执行更新操作等待10秒才会提交释放锁,所以事务2申请持锁需要等待,直到事务1结束才能获取到锁的持有权进行修改。事务2的执行信息中的[SQL 2]时间为8.787s(因为手速原因存在误差,实际应该为10秒左右)就能说明这一点。这样对同一数据的修改会变成串行化的修改,所以不会出现因为并发只进行一次+1的情况,也就不会出现丢失修改的问题。

[READ UNCOMMITTED]不能解决的问题

读未提交,顾名思义,一个事务可以读到另一个事务没有提交的内容,如果另一个事务进行回滚就会产生脏读。

我们来模拟一下脏读:

事务1

START TRANSACTION;
① UPDATE users SET state=1 WHERE id=1;
② SELECT sleep(5);
ROLLBACK;

事务2

START TRANSACTION;
① SELECT * FROM users WHERE id=1;
COMMIT;

事务1先于事务2执行。

事务1的执行信息

[SQL 1]START TRANSACTION;
受影响的行: 0
时间: 0.000s [SQL 2]
UPDATE users SET state=1 WHERE id=1;
受影响的行: 1
时间: 0.002s [SQL 3]
SELECT sleep(5);
受影响的行: 0
时间: 5.000s [SQL 4]
ROLLBACK;
受影响的行: 0
时间: 0.067s

事务2的执行信息

[SQL 1]START TRANSACTION;
受影响的行: 0
时间: 0.001s [SQL 2]
SELECT * FROM users WHERE id=1;
受影响的行: 0
时间: 0.001s [SQL 3]
COMMIT;
受影响的行: 0
时间: 0.000s

事务2的执行结果:



事务1和事务2都执行结束时,再进行一次查询的结果:



结论:读未提交[READ UNCOMMITTED]隔离级别解决不了脏读的问题,更解决不了不可重复读的问题。

分析:因为读未提交[READ UNCOMMITTED]隔离级别对应数据库的一级封锁协议。一级封锁协议在修改数据之前对其加X锁,直到事务结束释放X锁。读数据不加锁。因为事务1先执行修改,修改前申请持有X锁,持锁时间段为[SQL 2]开始前到[SQL 4]结束,持锁时间大约为5.069s。事务2执行读操作,不需要申请持锁,而是直接去磁盘读取数据。读取出的数据是事务1修改后的,而此时事务1回滚,修改的数据被还原,就产生了脏读现象。


[SERIALIZABLE]

这个级别的封锁就很好理解了,读加共享锁,写加排他锁,读写互斥。使用的悲观锁的理论,所有操作串行化执行,数据更加安全,但是并发能力非常差。如果你的业务并发的特别少或者没有并发,同时又要求数据及时可靠的话,可以使用这种模式。

我们重点探究的不是[READ UNCOMMITTED]和[SERIALIZABLE]级别,而是[READ COMMITTED]和[REPEATABLE READ]。如果您对此感兴趣可以看一下后两篇博客。


本文为博主学习感悟总结,水平有限,如果不当,欢迎指正。

如果您认为还不错,不妨点击一下下方的[【推荐】](javascript:void(0)

【眼见为实】自己动手实践理解数据库READ UNCOMMITED && SERIALIZABLE的更多相关文章

  1. 【眼见为实】自己动手实践理解数据库REPEATABLE READ && Next-Key Lock

    [REPEATABLE READ] 首先设置数据库隔离级别为可重复读(REPEATABLE READ): set global transaction isolation level REPEATAB ...

  2. 【眼见为实】自己动手实践理解数据库READ COMMITTED && MVCC

    [READ COMMITTED] 首先设置数据库隔离级别为读已提交(READ COMMITTED): set global transaction isolation level READ COMMI ...

  3. 【眼见为实】自己动手实践理解REPEATABLE READ && Next-Key Lock

    首先设置数据库隔离级别为可重复读(REPEATABLE READ): set global transaction isolation level REPEATABLE READ ; set sess ...

  4. 【眼见为实】自己动手实践理解READ COMMITTED && MVCC

    [眼见为实]自己动手实践理解 READ COMMITTED && MVCC 首先设置数据库隔离级别为读已提交(READ COMMITTED): set global transacti ...

  5. [转帖]Docker从入门到动手实践

    Docker从入门到动手实践 https://www.cnblogs.com/nsky/p/10853194.html dockerfile的图很好呢. 但是自己没有做实验 , 其实知识都挺好. do ...

  6. 【原创 Hadoop&Spark 动手实践 8】Spark 应用经验、调优与动手实践

    [原创 Hadoop&Spark 动手实践 7]Spark 应用经验.调优与动手实践 目标: 1. 了解Spark 应用经验与调优的理论与方法,如果遇到Spark调优的事情,有理论思考框架. ...

  7. 【原创 Hadoop&Spark 动手实践 9】Spark SQL 程序设计基础与动手实践(上)

    [原创 Hadoop&Spark 动手实践 9]SparkSQL程序设计基础与动手实践(上) 目标: 1. 理解Spark SQL最基础的原理 2. 可以使用Spark SQL完成一些简单的数 ...

  8. 【原创 Hadoop&Spark 动手实践 10】Spark SQL 程序设计基础与动手实践(下)

    [原创 Hadoop&Spark 动手实践 10]Spark SQL 程序设计基础与动手实践(下) 目标: 1. 深入理解Spark SQL 程序设计的原理 2. 通过简单的命令来验证Spar ...

  9. 【原创 Hadoop&Spark 动手实践 6】Spark 编程实例与案例演示

     [原创 Hadoop&Spark 动手实践 6]Spark 编程实例与案例演示 Spark 编程实例和简易电影分析系统的编写 目标: 1. 掌握理论:了解Spark编程的理论基础 2. 搭建 ...

随机推荐

  1. seek()方法的使用

    seek()方法用于移动文件读取指针到指定位置. file.seek()方法标准格式是:file.seek(offset,whence) offset:开始的偏移量,也就是代表需要移动偏移的字节数 w ...

  2. Win下Eclipse提交Hadoop程序出错:org.apache.hadoop.security.AccessControlException: Permission denied: user=D

    描述:在Windows下使用Eclipse进行Hadoop的程序编写,然后Run on hadoop 后,出现如下错误: 11/10/28 16:05:53 INFO mapred.JobClient ...

  3. SQLServer2005重建索引

    今天发现一个页面运行很慢,用SQL Server Profiler抓出了一条运行时间为12s的sql ) and wfinstance is not null and wftbrq>='2016 ...

  4. vue-cli 中的 webpack 配置详解

    本篇文章主要介绍了 vue-cli 2.8.2 中的 webpack 配置详解, 做个学习笔记 版本 vue-cli 2.8.1 (终端通过 vue -V 可查看) vue 2.2.2 webpack ...

  5. 酷派大神F2使用QPST进行nv备份恢复,解决无信号问题

    测试机器: 大神F2联通版 8675_W00 系统COOLUI55     写贴原因: 自己无意间刷错了包,结果手机无信号,进入工程模式怎么设置都没有用.尝试过系统还原(备份过).刷新的ROM.线刷, ...

  6. mysql 设置隔离级别

    查看隔离级别: mysql> select @@tx_isolation; +-----------------+ | @@tx_isolation | +-----------------+ ...

  7. 面试题21:如何判断二叉树是搜索二叉树BST?

    Given a binary tree, determine if it is a valid binary search tree (BST). Assume a BST is defined as ...

  8. 开启Apache Server Status

    开启Apache Server Status 发布时间:August 1, 2008 分类:Apache <DdZend工具提供下载> <PHP中MD5函数效率> Apache ...

  9. .Net Core使用 MiniProfiler 进行性能分析(转)

    转自:http://www.cnblogs.com/ideacore/p/9505425.html 官方文档: https://miniprofiler.com/dotnet/AspDotNetCor ...

  10. Java连接GBase并封装增删改查

    1.介绍 GBase 是南大通用数据技术有限公司推出的自主品牌的数据库产品,目前在国内数据库市场具有较高的品牌知名度;GBase品牌的系列数据库都具有自己鲜明的特点和优势:GBase 8a 是国内第一 ...