来自http://www.cnblogs.com/zhoujinyi/p/3437475.html
**很早之前写的文章,重新回顾和学习下,也可以看[这篇文章](http://tech.meituan.com/innodb-lock.html)说明。**
按照SQL:1992 事务隔离级别,InnoDB默认是可重复读的(REPEATABLE READ)。MySQL/InnoDB 提供SQL标准所描述的所有四个事务隔离级别。你可以在命令行用--transaction-isolation选项,或在选项文件里,为所有连接设置默认隔离级别。
例如,你可以在my.inf文件的[mysqld]节里类似如下设置该选项:
transaction-isolation = {READ-UNCOMMITTED | READ-COMMITTED | REPEATABLE-READ | SERIALIZABLE}
用户可以用SET TRANSACTION语句改变单个会话或者所有新进连接的隔离级别。它的语法如下:
SET [SESSION | GLOBAL] TRANSACTION ISOLATION LEVEL {READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIALIZABLE}
注意:默认的行为(不带session和global)是为下一个(未开始)事务设置隔离级别。如果你使用GLOBAL关键字,语句在全局对从那点开始创建的所有新连接(除了不存在的连接)设置默认事务级别。你需要SUPER权限来做这个。使用SESSION 关键字为将来在当前连接上执行的事务设置默认事务级别。 任何客户端都能自由改变会话隔离级别(甚至在事务的中间),或者为下一个事务设置隔离级别。
你可以用下列语句查询全局和会话事务隔离级别:
SELECT @@global.tx_isolation; SELECT @@session.tx_isolation; SELECT @@tx_isolation;
----以上手册中的理论知识;
===========================================================================================
隔离级别 脏读(Dirty Read) 不可重复读(NonRepeatable Read) 幻读(Phantom Read)
===========================================================================================
未提交读(Read uncommitted) 可能 可能 可能
已提交读(Read committed) 不可能 可能 可能
可重复读(Repeatable read) 不可能 不可能 可能
可串行化(Serializable ) 不可能 不可能 不可能
===========================================================================================
**·**未提交读(Read Uncommitted):允许脏读,也就是可能读取到其他会话中未提交事务修改的数据
**·**提交读(Read Committed):只能读取到已经提交的数据。Oracle等多数数据库默认都是该级别 (不重复读)
**·**可重复读(Repeated Read):可重复读。在同一个事务内的查询都是事务开始时刻一致的,InnoDB默认级别。在SQL标准中,该隔离级别消除了不可重复读,但是还存在幻象读
**·**串行读(Serializable):完全串行化的读,每次读都需要获得表级共享锁,读写相互都会阻塞
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
**用例子说明各个级别的情况:**
**① 脏读:** 脏读就是指当一个事务正在访问数据,并且对数据进行了修改,而这种修改还没有提交到数据库中,这时,另外一个事务也访问这个数据,然后使用了这个数据。
![复制代码](http://common.cnblogs.com/images/copycode.gif)
session 1:
mysql> select @@global.tx_isolation; +-----------------------+
| @@global.tx_isolation |
+-----------------------+
| REPEATABLE-READ |
+-----------------------+
1 row in set (0.00 sec)
mysql> select @@session.tx_isolation; +-----------------------+
| @@session.tx_isolation |
+-----------------------+
| REPEATABLE-READ |
+-----------------------+
1 row in set (0.00 sec)
mysql> start transaction;
Query OK, 0 rows affected (0.00 sec)
mysql> insert into ttd values(1);
Query OK, 1 row affected (0.05 sec)
mysql> select * from ttd; +------+
| id |
+------+
| 1 |
+------+
1 row in set (0.00 sec)
session 2:
mysql> select @@session.tx_isolation; +------------------------+
| @@session.tx_isolation |
+------------------------+
| REPEATABLE-READ |
+------------------------+
1 row in set (0.00 sec)
mysql> select @@global.tx_isolation; +-----------------------+
| @@global.tx_isolation |
+-----------------------+
| REPEATABLE-READ | --------该隔离级别下(除了 read uncommitted)
+-----------------------+
1 row in set (0.00 sec)
mysql> select * from ttd;
Empty set (0.00 sec) --------不会出现脏读
mysql> set session transaction isolation level read uncommitted;
Query OK, 0 rows affected (0.00 sec)
mysql> select @@session.tx_isolation; +------------------------+
| @@session.tx_isolation |
+------------------------+
| READ-UNCOMMITTED | --------该隔离级别下
+------------------------+
1 row in set (0.00 sec)
mysql> select * from ttd; +------+
| id |
+------+
| 1 | --------REPEATABLE-READ级别出现脏读
+------+
1 row in set (0.00 sec)
![复制代码](http://common.cnblogs.com/images/copycode.gif)
**结论:**session 2 在READ-UNCOMMITTED 下读取到session 1 中未提交事务修改的数据.
**② 不可重复读:**是指在一个事务内,多次读同一数据。在这个事务还没有结束时,另外一个事务也访问该同一数据。那么,在第一个事务中的两次读数据之间,由于第二个事务的修改,那么第一个事务两次读到的的数据可能是不一样的。这样就发生了在一个事务内两次读到的数据是不一样的,因此称为是不可重复读。
![复制代码](http://common.cnblogs.com/images/copycode.gif)
session 1:
mysql> select @@session.tx_isolation; +------------------------+
| @@session.tx_isolation |
+------------------------+
| READ-COMMITTED |
+------------------------+
1 row in set (0.00 sec)
mysql> start transaction;
Query OK, 0 rows affected (0.00 sec)
mysql> select * from ttd; +------+
| id |
+------+
| 1 |
+------+
1 row in set (0.00 sec)
session 2 :
mysql> select @@session.tx_isolation; +------------------------+
| @@session.tx_isolation |
+------------------------+
| REPEATABLE-READ |
+------------------------+
1 row in set (0.00 sec)
mysql> start transaction;
Query OK, 0 rows affected (0.00 sec)
mysql> select * from ttd; +------+
| id |
+------+
| 1 |
+------+
1 row in set (0.00 sec)
mysql> insert into ttd values(2); /也可以更新数据
Query OK, 1 row affected (0.00 sec)
mysql> select * from ttd; +------+
| id |
+------+
| 1 |
| 2 |
+------+
2 rows in set (0.00 sec)
mysql> commit;
Query OK, 0 rows affected (0.02 sec)
session 2 提交后,查看session 1 的结果;
session 1:
mysql> select * from ttd; +------+
| id |
+------+
| 1 | --------和第一次的结果不一样,READ-COMMITTED 级别出现了不重复读
| 2 |
+------+
2 rows in set (0.00 sec)
![复制代码](http://common.cnblogs.com/images/copycode.gif)
**③ 可重复读:**
![复制代码](http://common.cnblogs.com/images/copycode.gif)
session 1:
mysql> select @@session.tx_isolation; +------------------------+
| @@session.tx_isolation |
+------------------------+
| REPEATABLE-READ |
+------------------------+
1 row in set (0.00 sec)
mysql> start transaction;
Query OK, 0 rows affected (0.00 sec)
mysql> select * from ttd; +------+
| id |
+------+
| 1 |
| 2 |
+------+
2 rows in set (0.00 sec)
session 2 :
mysql> select @@session.tx_isolation; +------------------------+
| @@session.tx_isolation |
+------------------------+
| REPEATABLE-READ |
+------------------------+
1 row in set (0.00 sec)
mysql> start transaction;
Query OK, 0 rows affected (0.00 sec)
mysql> insert into ttd values(3);
Query OK, 1 row affected (0.00 sec)
mysql> commit;
Query OK, 0 rows affected (0.03 sec)
session 2 提交后,查看session 1 的结果;
session 1:
mysql> select * from ttd; +------+
| id |
+------+
| 1 | --------和第一次的结果一样,REPEATABLE-READ级别出现了重复读
| 2 |
+------+
2 rows in set (0.00 sec)
(commit session 1 之后 再select * from ttd 可以看到session 2 插入的数据3)
![复制代码](http://common.cnblogs.com/images/copycode.gif)
**④ 幻读:**第一个事务对一个表中的数据进行了修改,这种修改涉及到表中的全部数据行。同时,第二个事务也修改这个表中的数据,这种修改是向表中插入一行新数据。那么,以后就会发生操作第一个事务的用户发现表中还有没有修改的数据行,就好象发生了幻觉一样。
![复制代码](http://common.cnblogs.com/images/copycode.gif)
mysql>CREATE TABLE `t_bitfly` (
`id` bigint(20) NOT NULL default '0',
`value` varchar(32) default NULL, PRIMARY KEY (`id`)
) ENGINE=InnoDB
mysql> select @@global.tx_isolation, @@tx_isolation; +-----------------------+-----------------+
| @@global.tx_isolation | @@tx_isolation |
+-----------------------+-----------------+
| REPEATABLE-READ | REPEATABLE-READ |
+-----------------------+-----------------+
**实验一:**
t Session A Session B |
| START TRANSACTION; START TRANSACTION; |
| SELECT * FROM t_bitfly; | empty set
| INSERT INTO t_bitfly | VALUES (1, 'a'); |
| SELECT * FROM t_bitfly; | empty set
| COMMIT; |
| SELECT * FROM t_bitfly; | empty set
|
| INSERT INTO t_bitfly VALUES (1, 'a'); | ERROR 1062 (23000): | Duplicate entry '1' for key 1 v (shit, 刚刚明明告诉我没有这条记录的)
如此就出现了幻读,以为表里没有数据,其实数据已经存在了,傻乎乎的提交后,才发现数据冲突了。
**实验二:**
t Session A Session B |
| START TRANSACTION; START TRANSACTION; |
| SELECT * FROM t_bitfly; | +------+-------+
| | id | value |
| +------+-------+
| | 1 | a |
| +------+-------+
| INSERT INTO t_bitfly | VALUES (2, 'b'); |
| SELECT * FROM t_bitfly; | +------+-------+
| | id | value |
| +------+-------+
| | 1 | a |
| +------+-------+
| COMMIT; |
| SELECT * FROM t_bitfly; | +------+-------+
| | id | value |
| +------+-------+
| | 1 | a |
| +------+-------+
|
| UPDATE t_bitfly SET value='z'; | Rows matched: 2 Changed: 2 Warnings: 0
| (怎么多出来一行) |
| SELECT * FROM t_bitfly; | +------+-------+
| | id | value |
| +------+-------+
| | 1 | z |
| | 2 | z |
| +------+-------+
![复制代码](http://common.cnblogs.com/images/copycode.gif)
本事务中第一次读取出一行,做了一次更新后,另一个事务里提交的数据就出现了。也可以看做是一种幻读。
当隔离级别是可重复读,且禁用innodb_locks_unsafe_for_binlog的情况下,在搜索和扫描index的时候使用的next-key locks可以避免幻读。
再看一个实验,要注意,表t_bitfly里的id为主键字段。
![复制代码](http://common.cnblogs.com/images/copycode.gif)
**实验三:**
t Session A Session B |
| START TRANSACTION; START TRANSACTION; |
| SELECT * FROM t_bitfly | WHERE id=1
| FOR UPDATE; | +------+-------+
| | id | value |
| +------+-------+
| | 1 | a |
| +------+-------+
| INSERT INTO t_bitfly | VALUES (2, 'b'); | Query OK, 1 row affected |
| SELECT * FROM t_bitfly; | +------+-------+
| | id | value |
| +------+-------+
| | 1 | a |
| +------+-------+
| INSERT INTO t_bitfly | VALUES (0, '0'); | (waiting for lock ...then timeout) | ERROR 1205 (HY000): | Lock wait timeout exceeded; | try restarting transaction
|
| SELECT * FROM t_bitfly; | +------+-------+
| | id | value |
| +------+-------+
| | 1 | a |
| +------+-------+
| COMMIT; |
| SELECT * FROM t_bitfly; | +------+-------+
| | id | value |
| +------+-------+
| | 1 | a |
| +------+-------+
![复制代码](http://common.cnblogs.com/images/copycode.gif)
可以看到,用id
![复制代码](http://common.cnblogs.com/images/copycode.gif)
**实验四:一致性读和提交读**
t Session A Session B |
| START TRANSACTION; START TRANSACTION; |
| SELECT * FROM t_bitfly; | +----+-------+
| | id | value |
| +----+-------+
| | 1 | a |
| +----+-------+
| INSERT INTO t_bitfly | VALUES (2, 'b'); | COMMIT; |
| SELECT * FROM t_bitfly; | +----+-------+
| | id | value |
| +----+-------+
| | 1 | a |
| +----+-------+
|
| SELECT * FROM t_bitfly LOCK IN SHARE MODE; | +----+-------+
| | id | value |
| +----+-------+
| | 1 | a |
| | 2 | b |
| +----+-------+
|
| SELECT * FROM t_bitfly FOR UPDATE; | +----+-------+
| | id | value |
| +----+-------+
| | 1 | a |
| | 2 | b |
| +----+-------+
|
| SELECT * FROM t_bitfly; | +----+-------+
| | id | value |
| +----+-------+
| | 1 | a |
| +----+-------+
![复制代码](http://common.cnblogs.com/images/copycode.gif)
如果使用普通的读,会得到一致性的结果,如果使用了加锁的读,就会读到“最新的”“提交”读的结果。
本身,可重复读和提交读是矛盾的。在同一个事务里,如果保证了可重复读,就会看不到其他事务的提交,违背了提交读;如果保证了提交读,就会导致前后两次读到的结果不一致,违背了可重复读。
可以这么讲,InnoDB提供了这样的机制,在默认的可重复读的隔离级别里,可以使用加锁读去查询最新的数据(提交读)。
MySQL InnoDB的可重复读并不保证避免幻读,需要应用使用加锁读来保证。而这个加锁度使用到的机制就是[next-key locks](http://www.cnblogs.com/zhoujinyi/p/3435982.html)。
**总结:**
四个级别逐渐增强,每个级别解决一个问题。事务级别越高,性能越差,大多数环境read committed 可以用.记住4个隔离级别的特点(上面的例子);
~~~~~~~~~~~~~~~ 万物之中,希望至美 ~~~~~~~~~~~~~~~
- 数据库
- 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分析和设计(二)
- 数据库命名规范--通用