MySQL InnoDB四个事务级别 与 脏读、不重复读、幻读

最新推荐文章于 2024-07-16 11:14:25 发布
最新推荐文章于 2024-07-16 11:14:25 发布
阅读量623 收藏
点赞数
分类专栏： MYSQL基础知识

1、MySQL InnoDB事务隔离级别脏读、可重复读、幻读

MySQL InnoDB事务的隔离级别有四级，默认是“可重复读”（REPEATABLE READ）。

·        1）.未提交读（READUNCOMMITTED）。另一个事务修改了数据，但尚未提交，而本事务中的SELECT会读到这些未被提交的数据（脏读）( 隔离级别最低，并发性能高 )。

·        2）.提交读（READCOMMITTED）。本事务读取到的是最新的数据（其他事务提交后的）。问题是，在同一个事务里，前后两次相同的SELECT会读到不同的结果（不重复读）。会出现不可重复读、幻读问题（锁定正在读取的行）

·        3）.可重复读（REPEATABLEREAD）。在同一个事务里，SELECT的结果是事务开始时时间点的状态，因此，同样的SELECT操作读到的结果会是一致的。但是，会有幻读现象（稍后解释）。会出幻读（锁定所读取的所有行）。

·        4）.串行化（SERIALIZABLE）。读操作会隐式获取共享锁，可以保证不同事务间的互斥（锁表）。

‘

四个级别逐渐增强，每个级别解决一个问题。

·        1）.脏读。另一个事务修改了数据，但尚未提交，而本事务中的SELECT会读到这些未被提交的数据。

·        2）.不重复读。解决了脏读后，会遇到，同一个事务执行过程中，另外一个事务提交了新数据，因此本事务先后两次读到的数据结果会不一致。

·        3）.幻读。解决了不重复读，保证了同一个事务里，查询的结果都是事务开始时的状态（一致性）。但是，如果另一个事务同时提交了新数据，本事务再更新时，就会“惊奇的”发现了这些新数据，貌似之前读到的数据是“鬼影”一样的幻觉。

    具体地：

    1). 脏读 

      首先区分脏页和脏数据

      脏页是内存的缓冲池中已经修改的page，未及时flush到硬盘，但已经写到redo log中。读取和修改缓冲池的page很正常，可以提高效率，flush即可同步。脏数据是指事务对缓冲池中的行记录record进行了修改，但是还没提交！！！，如果这时读取缓冲池中未提交的行数据就叫脏读，违反了事务的隔离性。脏读就是指当一个事务正在访问数据，并且对数据进行了修改，而这种修改还没有提交到数据库中，这时，另外一个事务也访问这个数据，然后使用了这个数据。

    2). 不可重复读 

     是指在一个事务内，多次读同一数据。在这个事务还没有结束时，另外一个事务也访问该同一数据。那么，在第一个事务中的两次读数据之间，由于第二个事务的修改，第二个事务已经提交。那么第一个事务两次读到的的数据可能是不一样的。这样就发生了在一个事务内两次读到的数据是不一样的，因此称为是不可重复读。例如，一个编辑人员两次读取同一文档，但在两次读取之间，作者重写了该文档。当编辑人员第二次读取文档时，文档已更改。原始读取不可重复。如果只有在作者全部完成编写后编辑人员才可以读取文档，则可以避免该问题

    3). 幻读 :

     是指当事务不是独立执行时发生的一种现象，例如第一个事务对一个表中的数据进行了修改，这种修改涉及到表中的全部数据行。同时，第二个事务也修改这个表中的数据，这种修改是向表中插入一行新数据。那么，以后就会发生操作第一个事务的用户发现表中还有没有修改的数据行，就好象发生了幻觉一样。例如，一个编辑人员更改作者提交的文档，但当生产部门将其更改内容合并到该文档的主复本时，发现作者已将未编辑的新材料添加到该文档中。如果在编辑人员和生产部门完成对原始文档的处理之前，任何人都不能将新材料添加到文档中，则可以避免该问题。


2、隔离级别实验

       以下实验基于博主MySQL Server 5.6

       首先创建一个表，如下：

[sql]  view plain  copy
  1. USE test;  
  2. CREATE TABLE `t` (  
  3.   
  4.   `a` int(11) NOT NULL PRIMARY KEY  
  5.   
  6. ) ENGINE=InnoDB DEFAULT CHARSET=utf8;  

2.1、实验一：解释脏读、可重复读问题  

 

事务A READ-UNCOMMITTED

事务B READ-COMMITTED,

事务C-1 REPEATABLE-READ

事务C-2 REPEATABLE-READ

事务D SERIALIZABLE

set autocommit =0;

     

start transaction ;

   

start transaction;

 

insert into t(a)values(4);

     
 

select * from t;

1,2,3,4(脏读：读取到了未提交的事务中的数据)

select * from t;

1,2,3（解决脏读）

select * from t;

1,2,3

select * from t;

1,2,3

select * from t;

1,2,3

      
      

commit;

     
 

select * from t:

1,2,3,4

select * from t:

1,2,3,4

select * from t:

1,2,3,4 (与上面的不在一个事务中，所以读到为事务提交后最新的，所以可读到4)

select * from t:

1,2,3（重复读：由于与上面的在一个事务中，所以只读到事务开始事务的数据，也就是重复读）

select * from t:

1,2,3,4

    

commit（提交事务，下面的就是一个新的事务，所以可以读到事务提交以后的最新数据）

 
    

select * from t:

1,2,3,4

 

READ-UNCOMMITTED 会产生脏读，基本很少适用于实际场景，所以基本不使用。


2.2、实验二：测试READ-COMMITTED与REPEATABLE-READ

事务A

事务B READ-COMMITTED

事务C REPEATABLE-READ

set autocommit =0;

  

start transaction ;

start transaction;

start transaction;

insert into t(a)values(4);

  
 

select * from t;

1,2,3

select * from t;

1,2,3

   
   

commit;

  
 

select * from t:

1,2,3,4

select * from t:

1,2,3（重复读：由于与上面的在一个事务中，所以只读到事务开始事务的数据，也就是重复读）

  

commit（提交事务，下面的就是一个新的事务，所以可以读到事务提交以后的最新数据）

  

select * from t:

1,2,3,4

REPEATABLE-READ可以确保一个事务中读取的数据是可重复的，也就是相同的读取（第一次读取以后，即使其他事务已经提交新的数据，同一个事务中再次select也并不会被读取）。

READ-COMMITTED只是确保读取最新事务已经提交的数据。

当然数据的可见性都是对不同事务来说的，同一个事务，都是可以读到此事务中最新数据的。如下，

[sql]  view plain  copy
  1. start transaction;  
  2. insert into t(a)values(4);  
  3. select *from t;  
  4.   
  5. 1,2,3,4;  
  6.   
  7. insert into t(a)values(5);  
  8. select *from t;  
  9.   
  10. 1,2,3,4,5;  

2.3、实验三：测试SERIALIZABLE事务对其他的影响


事务A SERIALIZABLE

事务B READ-UNCOMMITTED

事务C READ-COMMITTED,

事务D REPEATABLE-READ

事务E SERIALIZABLE

set autocommit =0;

    

start transaction ;

  

start transaction;

 

select a from t union all select sleep(1000) from dual;

    
 

insert into t(a)values(5);

insert into t(a)values(5);

insert into t(a)values(5);

insert into t(a)values(5);

 

ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

 

SERIALIZABLE 串行化执行，导致所有其他事务不得不等待事务A结束才行可以执行，这里特意使用了sleep函数，直接导致事务B,C,D,E等待事务A持有释放的锁。由于我sleep了1000秒，而innodb_lock_wait_timeout为120s。所以120s到了就报错HY000错误。

SERIALIZABLE是相当严格的串行化执行模式，不管是读还是写，都会影响其他读取相同的表的事务。是严格的表级读写排他锁。也就失去了innodb引擎的优点。实际应用很少。


2.4、实验四：幻读

一些文章写到InnoDB的可重复读避免了“幻读”（phantom read），这个说法并不准确。做个实验：(以下所有试验要注意存储引擎和隔离级别)

[sql]  view plain  copy
  1. CREATE TABLE `t_bitfly` (  
  2. `id` bigint(20) NOT NULL default '0',  
  3. `value` varchar(32) default NULL,  
  4. PRIMARY KEY (`id`)  
  5. ) ENGINE=InnoDB DEFAULT CHARSET=utf8;  
  6.   
  7. select @@global.tx_isolation, @@tx_isolation;  
  8. +-----------------------+-----------------+  
  9. | @@global.tx_isolation | @@tx_isolation  |  
  10. +-----------------------+-----------------+  
  11. | REPEATABLE-READ       | REPEATABLE-READ |  
  12. +-----------------------+-----------------+  

实验4-1：

Session A

Session B

start transaction ;start transaction ;

SELECT * FROM t_bitfly;
empty set

 


INSERT INTO t_bitfly VALUES (1, 'a');COMMIT;
SELECT * FROM t_bitfly;
| empty set


INSERT INTO t_bitfly VALUES (1, 'a');
|ERROR 1062 (23000):
|Duplicate entry '1' for key 1
(刚刚明明告诉我没有这条记录的)		I
如此就出现了幻读，以为表里没有数据，其实数据已经存在了，提交后，才发现数据冲突了。


实验4-2：

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     |
| +------+-------+

 

本事务中第一次读取出一行，做了一次更新后，另一个事务里提交的数据就出现了。也可以看做是一种幻读。


附说明

那么，InnoDB指出的可以避免幻读是怎么回事呢？

http://dev.mysql.com/doc/refman/5.0/en/innodb-record-level-locks.html

By default, InnoDB operatesin REPEATABLE READ transaction isolation level and with the innodb_locks_unsafe_for_binlog system variable disabled. In this case, InnoDB uses next-key locks for searches and index scans, which prevents phantom rows (see Section 13.6.8.5, “Avoidingthe Phantom Problem Using Next-Key Locking”).

准备的理解是，当隔离级别是可重复读，且禁用innodb_locks_unsafe_for_binlog的情况下，在搜索和扫描index的时候使用的next-keylocks可以避免幻读。

关键点在于，是InnoDB默认对一个普通的查询也会加next-key locks，还是说需要应用自己来加锁呢？如果单看这一句，可能会以为InnoDB对普通的查询也加了锁，如果是，那和序列化（SERIALIZABLE）的区别又在哪里呢？

MySQL manual里还有一段：

13.2.8.5. Avoiding the PhantomProblem Using Next-Key Locking (http://dev.mysql.com/doc/refman/5.0/en/innodb-next-key-locking.html)

Toprevent phantoms, InnoDB usesan algorithm called next-key locking that combinesindex-row locking with gap locking.

Youcan use next-key locking to implement a uniqueness check in your application:If you read your data in share mode and do not see a duplicate for a row you are going to insert, then you can safely insert your row and know that the next-key lock set on the success or of your row during the read prevents anyone mean while inserting a duplicate for your row. Thus, the next-key locking enables you to “lock” the nonexistence of something in your table.

我的理解是说，InnoDB提供了next-key locks，但需要应用程序自己去加锁。manual里提供一个例子：

SELECT * FROM child WHERE id> 100 FOR UPDATE;

这样，InnoDB会给id大于100的行（假如child表里有一行id为102），以及100-102，102+的gap都加上锁。

可以使用show engine innodb status来查看是否给表加上了锁。


再看一个实验，要注意，表t_bitfly里的id为主键字段。

实验4-3：

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     |
| +------+-------+

 


 

可以看到，用id<=1加的锁，只锁住了id<=1的范围，可以成功添加id为2的记录，添加id为0的记录时就会等待锁的释放。

附说明：

MySQL manual里对可重复读里的锁的详细解释：

http://dev.mysql.com/doc/refman/5.0/en/set-transaction.html#isolevel_repeatable-read

For locking reads (SELECT with FOR UPDATE or LOCK IN SHARE MODE),UPDATE, and DELETE statements, locking depends on whether the statement uses a unique index with a unique search condition, or a range-type search condition. For a unique index with a unique search condition, InnoDB locks only the index record found, not the gap before it. For other search conditions, InnoDB locks the index range scanned, using gap locks or next-key (gap plus index-record)locks to block insertions by other sessions into the gaps covered by the range.


一致性读和提交读，先看实验，

实验4-4：

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     |
| +----+-------+

 


附说明：如果使用普通的读，会得到一致性的结果，如果使用了加锁的读，就会读到“最新的”“提交”读的结果。

本身，可重复读和提交读是矛盾的。在同一个事务里，如果保证了可重复读，就会看不到其他事务的提交，违背了提交读；如果保证了提交读，就会导致前后两次读到的结果不一致，违背了可重复读。

可以这么讲，InnoDB提供了这样的机制，在默认的可重复读的隔离级别里，可以使用加锁读去查询最新的数据。

http://dev.mysql.com/doc/refman/5.0/en/innodb-consistent-read.html

If you want to see the “freshest” state of the database, you should use either theREAD COMMITTED isolation level or a locking read:
SELECT * FROM t_bitfly LOCK IN SHARE MODE;

------

3、总结

结论：MySQL InnoDB事务默认隔离级别是可重复读并不保证避免幻读，需要应用使用加锁读来保证。而这个加锁度使用到的机制就是next-key locks。

文章源于http://www.bitscn.com/pdb/mysql/201405/227973.html，修改了文章部分内容

anzhen0429
关注
专栏目录
MySQL InnoDB事务隔离级别与锁机制深入解析
fudaihb的博客
04-20 1397
随着数据库应用的日益复杂和并发用户数量的增加，选择合适的事务隔离级别和恰当的锁策略变得尤为关键。不恰当的隔离级别或者锁策略可能导致诸如脏读、不可重复读、幻读以及死锁等问题，严重影响数据库的性能和数据的一致性。 本文将深入探讨MySQL中InnoDB存储引擎的事务隔离级别和锁机制，帮助读者理解它们的工作原理、特性和应用场景。通过对这些内容的深入解析，读者将能够更好地理解如何在实际应用中选择合适的事务隔离级别，以及如何使用锁机制来优化数据库性能，确保数据的一致性和完整性。
MySQL事务隔离级别REPEATABLE READ(可重复读)造成多进程mysql_store_result查询结果不正确
Just do it
04-02 2938
MySQL事务隔离级别介绍及设置READ UNCOMMITTED(未提交)即使没有提交，对其它事务也可见。未提交的数据会引起脏读(Dirty Read)。测试流程：1、A设置read-uncommitted, start transaction2、B执行start transaction，修改一条记录，3、A查询记录，得到了以为正确的记录4、B回滚。问题：A读到了B没有提交的记录，也就是脏读。 R...
一文详解MySQL InnoDB脏读、不可重复读、幻读（通俗易懂）
Java搜索工程技术栈
03-08 539
在MySQL的众多存储引擎中，只有InnoDB支持事务，所有这里说的事务隔离级别指的是InnoDB下的事务隔离级别。 MySQL 是支持多事务并发执行的。否则来一个事务处理一个请求，处理一个人请求的时候，其它事务都等着，那估计都没人敢用MySQL作为数据库,因为用户体验太差，估计都要砸键盘了。 既然事务可以并发操作,这里就有一些问题：一个事务在写数据的时候，另一个事务要读这行数据，该怎么处理？一个事务在写数据，另一个数据也要写这行数据，又该怎么处理这个冲突？ 这就是并发事务所产生的一些问题。具体来.
MySQL事务隔离级别中可重复读与幻读
a18827547638的博客
12-06 1405
MySQL事务隔离级别中可重复读与幻读
为什么 MySQL 事务默认隔离级别是可重复读？
最新发布
codenav的博客
07-16 488
MySQL 默认的隔离级别是可重复读（ Repeatable Read ），即 RR。
MySQL事务隔离级别详解：脏读、不可重复读与幻读
这样可以避免脏读、不可重复读和幻读，但代价是并发性能大幅度降低，因为每个事务都需要等待前一个事务完成。 选择合适的事务隔离级别取决于具体的应用场景和需求。通常，对于大多数业务，READ COMMITTED或...
MySQL InnoDB锁与隔离级别详解：从实战角度看脏读、不可重复读与幻读
不同的隔离级别提供不同程度的保护，以防止脏读、不可重复读和幻读等问题： 1. **Read Uncommitted (RU)**：这是最低的隔离级别，事务可以读取其他事务未提交的数据，可能导致脏读。事务A可能看到其他事务未完成的...
MySQL中Innodb的事务隔离级别和锁的关系的讲解教程
09-10
MySQL中的InnoDB存储引擎提供了四个事务隔离级别，分别是：读未提交（Read Uncommitted）、读已提交（Read Committed）、可重复读（Repeated Read）和可串行化（Serializable）。 脏读发生在事务读取了另一个尚未...
InnoDB可重复读隔离级别下如何避免幻读？
qq_41627514的博客
02-22 1030
InnoDB可重复读隔离级别下如何避免幻读？ 表象：快照读（非阻塞读）—伪MVCC 内在：next-key锁，（行锁+gap锁） 当前读：加锁的增删改查语句，无论什么锁，因为读取的是当前最新版本，还要保证并发事务不能修改当前记录，对读取记录加锁。 快照读：可能读取到的数据不是最新版本而是历史版本。 read committed级别下。当前读与快照读读取的版本一样。 repeatable read...
MySQL InnoDB 默认的事务隔离级别是什么？如何修改？
学亮编程手记
11-27 638
InnoDB 默认的事务隔离是 repetable read（可重复读）；
探究InnoDB可重复读
寻道
10-17 3398
在RC（Read Committed）和RR（Repeatable Read）两种事务隔离级别下，InnoDB存在两种数据读取方式： 快照读（Snapshot Read） 故名思意，快照读读取的都是快照数据，快照怎么来，在InnoDB引擎下是基于undo log，那undo log又是什么？举例说明，假设有这样一个表： -- 表结构 CREATE TABLE `innodb_test
InnoDB---可重复读隔离级别的实现
那海蓝蓝的博客
04-19 3084
可重复读的实现     可重复读隔离级别，简称RR，在2.1.1节，我们说过：     Repeatable Read（可重复读）：一个事务在执行过程中可以看到其他事务已经提交的新插入的记录（读已经提交的，其实是读早于本事务开始且已经提交的），但是不能看到其他事务对已有记录的更新（即晚于本事务开始的），并且，该事务不要求与其他事务是“可串行化”的。     这句话的核心，是“但是不能看到其他
ENGINE=InnoDB DEFAULT CHARSET=utf-8
weixin_44706350的博客
03-24 8416
ENGINE=InnoDB DEFAULT CHARSET=utf-8 ENGINE=InnoDB使用InnoDB引擎，InnoDB，是MySQL的数据库引擎之一，为MySQL AB发布binary的标准之一。 DEFAULT CHARSET=utf8 数据库默认编码为utf-8 AUTO_INCREMENT=1 自增键的起始序号为1，AUTO_INCREMENT会在新记录插入表中时生成一个唯一的数字。希望在每次插入新记录时，自动地创建主键字段的值，可以在表中创建一个 auto-increment 字段。
Innodb中的事务隔离级别和锁的关系
美团技术团队
08-20 1422
前言: 我们都知道事务的几种性质，数据库为了维护这些性质，尤其是一致性和隔离性，一般使用加锁这种方式。同时数据库又是个高并发的应用，同一时间会有大量的并发访问，如果加锁过度，会极大的降低并发处理能力。所以对于加锁的处理，可以说就是数据库对于事务处理的精髓所在。这里通过分析MySQL中InnoDB引擎的加锁机制，来抛砖引玉，让读者更好的理解，在事务处理中数据库到底做了什么。 #一...
mysql innodb 默认隔离级别_MySQL InnoDB 四种事务隔离级别
weixin_36488760的博客
01-27 1471
InnoDB默认是可重复读的(REPEATABLE READ)修改全局默认的事务级别，在my.inf文件的[mysqld]节里类似如下设置该选项(不推荐)transaction-isolation = {READ-UNCOMMITTED | READ-COMMITTED | REPEATABLE-READ | SERIALIZABLE}改变单个会话或者所有新进连接的隔离级别(推荐使用)SET [S...
mysql-Innodb事务隔离级别-repeatable read详解
06-16 3772
  原文地址：http://orzdba.wordpress.com/2011/03/03/transaction_isolation_levels/一、事务隔离级别ANSI/ISO SQL标准定义了4中事务隔离级别：未提交读（read uncommitted），提交读（read committed），重复读（repeatable read），串行读（serializable）
【数据库】Innodb如何保证可重复读
彷徨之犬的博客
12-03 1137
明确一些概念 DB_TRX_ID: 记录当前数据行最后一次的更新和插入的事务id DB_ROLL_PTR: 指向当前记录项的undo log信息 DB_ROW_ID：标识插入的新数据行 如何保证可重复读：事务活跃数组array 1.事务开启后，有一个数组array用来维护当前活跃的事务id（开启未提交） 2.事务id最大值+1记作高水位 3.事务id最小值记作低水位 每一行数据都会有一个undo ...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值