来自http://www.jianshu.com/p/4e3edbedb9a8
好久没碰数据库了,只是想起自己当时在搞数据库的时候在事务隔离级别这块老是卡,似懂非懂的。现在想把这块整理出来,尽量用最简洁的语言描述出来,供新人参考。
首先创建一个表account。创建表的过程略过(由于InnoDB存储引擎支持事务,所以将表的存储引擎设置为InnoDB)。表的结构如下:
![](http://upload-images.jianshu.io/upload_images/2607748-8179e4fc53b73fc0.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
表结构
然后往表中插入两条数据,插入后结果如下:
![](http://upload-images.jianshu.io/upload_images/2607748-b9bbca7325852c48.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
数据
为了说明问题,我们打开两个控制台分别进行登录来模拟两个用户(暂且成为用户A和用户B吧),并设置当前MySQL会话的事务隔离级别。
## 一. read uncommitted(读取未提交数据)
具体用户A的操作如下:
~~~
set session transaction isolation level read uncommitted;
start transaction;
select * from account;
~~~
结果如下:
![](http://upload-images.jianshu.io/upload_images/2607748-b9bbca7325852c48.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
数据
用户B的操作如下:
~~~
set session transaction isolation level read uncommitted;
start transaction;
update account set account=account+200 where id = 1;
~~~
随后我们在A用户中查询数据,结果如下:
![](http://upload-images.jianshu.io/upload_images/2607748-a0fbe25be92e6621.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
uncommittedA数据
### 结论一:
### 我们将事务隔离级别设置为read uncommitted,即便是事务没有commit,但是我们仍然能读到未提交的数据,这是所有隔离级别中最低的一种。
#### *那么这么做有什么问题吗?*
那就是我们在一个事务中可以随随便便读取到其他事务未提交的数据,这还是比较麻烦的,我们叫**脏读**。我不知道这个名字是怎么起的,为了增强大家的印象,可以这么想,这个事务好轻浮啊,饥渴到连别人没提交的东西都等不及,真脏,呸!
实际上我们的数据改变了吗?
*答案是否定的,因为只有事务commit后才会更新到数据库。*
## 二. read committed(可以读取其他事务提交的数据)---大多数数据库默认的隔离级别
同样的办法,我们将用户B所在的会话当前事务隔离级别设置为read commited。
在用户A所在的会话中我们执行下面操作:
~~~
update account set account=account-200 where id=1;
~~~
![](http://upload-images.jianshu.io/upload_images/2607748-9234df9cc22f3a5b.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
read committed
我们将id=1的用户account减200。然后查询,发现id=1的用户account变为800。
在B用户所在的会话中查询:
~~~
select * from account;
~~~
结果如下:
![](http://upload-images.jianshu.io/upload_images/2607748-9d518364ab9b4cc0.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
read committedB
我们会发现数据并没有变,还是1000。
接着在会话A中我们将事务提交:
~~~
commit;
~~~
在会话B中查询结果如下:
![](http://upload-images.jianshu.io/upload_images/2607748-d9436e13f7be17df.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
read committedB1
### 结论二:
### 当我们将当前会话的隔离级别设置为read committed的时候,当前会话只能读取到其他事务提交的数据,未提交的数据读不到。
#### *那么这么做有什么问题吗?*
那就是我们在会话B同一个事务中,读取到两次不同的结果。这就造成了不可重复读,就是两次读取的结果不同。这种现象叫**不可重复读**。
## 三. repeatable read(可重读)---MySQL默认的隔离级别
现在有个需求,就是老板说在同一个事务中查询结果必须保持一致,如果你是数据库,你会怎么做?数据库是这么做的。
在会话B中我们当前事务隔离级别为repeatable read。具体操作如下:
~~~
set session transaction isolation level repeatable read;
start transaction;
~~~
接着在会话B中查询数据:
![](http://upload-images.jianshu.io/upload_images/2607748-29f109af023757b4.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
repeatablereadB1
我们在A用户所在会话中为表account添加一条数据:
~~~
insert into account(id,account) value(3,1000);
commit;
~~~
然后我们查询看数据插入是否成功:
![](http://upload-images.jianshu.io/upload_images/2607748-62d0f8d3524f5e2f.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
repeatable readA
回到B用户所在的会话,我们查询结果:
![](http://upload-images.jianshu.io/upload_images/2607748-bad6b8fcf218f2f5.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
repeatablereadB2
用户B在他所在的会话中想插入一条新数据id=3,value=1000。来我们操作下:
![](http://upload-images.jianshu.io/upload_images/2607748-da79749a21d4568f.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
readpeatablereadB3
#### *什么?竟然插不进去,说我数据重复?*
用户B当然不服啊,因为查询到数据只有两条啊,为什么插入id=3说我数据重复了呢?
我再看一遍,莫非我眼花了?
![](http://upload-images.jianshu.io/upload_images/2607748-bad6b8fcf218f2f5.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
repeatablereadB2
试想一下,在实际中用户A和用户B肯定是相互隔离的,彼此不知道操作什么。用户B碰到这种现象,肯定会炸毛的啊,明明不存在的数据,插入却说主键id=3数据重复了。
### 结论三:
### 当我们将当前会话的隔离级别设置为repeatable read的时候,当前会话可以重复读,就是每次读取的结果集都相同,而不管其他事务有没有提交。
### *有什么问题吗?*
管他呢,老板的要求满足了。要一个事务中读取的数据一致(可重复读)。我只能这么做啊,打肿脸装胖子。数据已经发生改变,但是我还是要保持一致。但是,出现了用户B面对的问题,这种现象叫**幻读**(记得当时就在这个地方纠结好久,到底什么是幻读啊)。
## 四. serializable(串行化)
同样,我们将用户B所在的会话的事务隔离级别设置为serializable并开启事务。
~~~
set session transaction isolation level serializable;
start transaction;
~~~
在用户B所在的会话中我们执行下面操作:
~~~
select * from account;
~~~
结果如下:
![](http://upload-images.jianshu.io/upload_images/2607748-ae20fd30cc93b41d.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
serializableA
那我们这个时候在用户A所在的会话中写数据呢?
![](http://upload-images.jianshu.io/upload_images/2607748-91a0ce7dba1971e9.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
readcommittedA1
我们发现用户A所在的会话陷入等待,如果超时(这个时间可以进行配置),会出现Lock wait time out提示:
![](http://upload-images.jianshu.io/upload_images/2607748-e3f08966650c0f8e.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
readcommittedA2
如果在等待期间我们用户B所在的会话事务提交,那么用户A所在的事务的写操作将提示操作成功。
### 结论四:
### 当我们将当前会话的隔离级别设置为serializable的时候,其他会话对该表的写操作将被挂起。可以看到,这是隔离级别中最严格的,但是这样做势必对性能造成影响。所以在实际的选用上,我们要根据当前具体的情况选用合适的。
作者:伞U
链接:http://www.jianshu.com/p/4e3edbedb9a8
來源:简书
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
- 数据库
- CAP定理
- 关系模型
- 关系数据库
- NoSQL
- ODBC
- JDBC
- ODBC、JDBC和四种驱动类型
- mysql
- 安装与配置
- CentOS 7 安装 MySQL
- 优化
- 比较全面的MySQL优化参考
- 1、硬件层相关优化
- 1.1、CPU相关
- 1.2、磁盘I/O相关
- 2、系统层相关优化
- 2.1、文件系统层优化
- 2.2、其他内核参数优化
- 3、MySQL层相关优化
- 3.1、关于版本选择
- 3.2、关于最重要的参数选项调整建议
- 3.3、关于Schema设计规范及SQL使用建议
- 3.4、其他建议
- 后记
- Mysql设计与优化专题
- ER图,数据建模与数据字典
- 数据中设计中的范式与反范式
- 字段类型与合理的选择字段类型
- 表的垂直拆分和水平拆分
- 详解慢查询
- mysql的最佳索引攻略
- 高手详解SQL性能优化十条经验
- 优化SQL查询:如何写出高性能SQL语句
- MySQL索引原理及慢查询优化
- 数据库SQL优化大总结之 百万级数据库优化方案
- 数据库性能优化之SQL语句优化1
- 【重磅干货】看了此文,Oracle SQL优化文章不必再看!
- MySQL 对于千万级的大表要怎么优化?
- MySQL 数据库设计总结
- MYSQL性能优化的最佳20+条经验
- 数据操作
- 数据语句操作类型
- DCL
- 修改Mysql数据库名的5种方法
- DML
- 连接
- 连接2
- DDL
- 数据类型
- 字符集
- 表引擎
- 索引
- MySQL理解索引、添加索引的原则
- mysql建索引的几大原则
- 浅谈mysql的索引设计原则以及常见索引的区别
- 常用工具简介
- QA
- MySQL主机127.0.0.1与localhost区别总结
- 视图(view)
- 触发器
- 自定义函数和存储过程的使用
- 事务(transaction)
- 范式与反范式
- 常用函数
- MySQL 数据类型 详解
- Mysql数据库常用分库和分表方式
- 隔离级别
- 五分钟搞清楚MySQL事务隔离级别
- mysql隔离级别及事务传播
- 事务隔离级别和脏读的快速入门
- 数据库引擎中的隔离级别
- 事务隔离级别
- Innodb中的事务隔离级别和锁的关系
- MySQL 四种事务隔离级的说明
- Innodb锁机制:Next-Key Lock 浅谈
- SQL函数和存储过程的区别
- mongo
- MongoDB设置访问权限、设置用户
- redis
- ORM
- mybatis
- $ vs #
- mybatis深入理解(一)之 # 与 $ 区别以及 sql 预编译
- 电商设计
- B2C电子商务系统研发——概述篇
- B2C电子商务系统研发——商品数据模型设计
- B2C电子商务系统研发——商品模块E-R图建模
- B2C电子商务系统研发——商品SKU分析和设计(一)
- B2C电子商务系统研发——商品SKU分析和设计(二)
- 数据库命名规范--通用