zoukankan      html  css  js  c++  java

  • InnoDB的锁机制浅析(三)—幻读

    文章总共分为五个部分：

    大而全版（五合一）：InnoDB的锁机制浅析(All in One)

    前言

    这一章节，我们通过幻读，逐步展开对InnoDB锁的探究。

    1 幻读概念

    解释了不同概念的锁的作用域，我们来看一下幻读到底是什么。幻读在RR条件下是不会出现的。因为RR是Repeatable Read，它是一种事务的隔离级别，直译过来也就是“在同一个事务中，同样的查询语句的读取是可重复”，也就是说他不会读到”幻影行”(其他事务已经提交的变更)，它读到的只能是重复的(无论在第一次查询之后其他事务做了什么操作，第二次查询结果与第一次相同)。

    上面的例子都是使用for update，这种读取操作叫做当前读，对于普通的select语句均为快照读。

    当前读，又叫加锁读，或者 阻塞读。这种读取操作不再是读取快照，而是读取最新版本并且加锁。
    快照读不会添加任何锁。

    官方文档对于幻读的定义是这样的：

    原文：The so-called phantom problem occurs within a transaction when the same query produces different sets of rows at different times. For example, if a SELECT is executed twice, but returns a row the second time that was not returned the first time, the row is a “phantom” row.
    手动无脑翻译：所谓的幻影行问题是指，在同一个事务中，同样的查询语句执行多次，得到了不同的结果，这就是幻读。例如，如果同一个SELECT语句执行了两次，第二次执行的时候比第一次执行时多出一行，则该行就是所谓的幻影行。

    The so-called phantom problem occurs within a transaction when the same query produces different sets of rows at different times.，这句话看起来应该是不可重复读的定义，同样的查询得到了不同的结果(两次结果不是重复的)，但是后面的举例给出了幻读真正的定义，第二次比第一次多出了一行。也就是说，幻读的出现有这样一个前提，第二次查询前其他事务提交了一个INSERT插入语句。而不可重复读出现的前提是第二次查询前其他事务提交了UPDATE或者DELETE操作。

    mysql的快照读，使得在RR的隔离级别上在next-Key的作用区间内，制造了一个快照副本，这个副本是隔离的，无论副本对应的区间里的数据被其他事务如何修改，在当前事务中，取到的数据永远是副本中的数据。
    RR级别下之所以可以读到之前版本的数据，是由于数据库的MVCC(Multi-Version Concurrency Control，多版本并发控制)。参见InnoDB Multi-Versioning

    有些文章中提到“RR也不能完全避免幻读”，实际上官方文档实际要表达的意义是“在同一个事务内，多次连续查询的结果是一样的，不会因其他事务的修改而导致不同的查询结果”，这里先给出实验结论：

    1.当前事务如果未发生更新操作(增删改)，快照版本会保持不变，多次查询读取的副本是同一个。
    2.当前事务如果发生更新(增删改)，再次查询时，会刷新快照版本。

    示例的基础是一个只有两列的数据库表。

    mysql> CREATE TABLE test (
id int(11) NOT NULL,
code int(11) NOT NULL, 
PRIMARY KEY(id), 
KEY (code)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; 

mysql> INSERT INTO test(id,code) values(1,1),(10,10);

    2 RC级别下的幻读

    RC情况下会出现幻读。
    首先设置隔离级别为RC,SET SESSION tx_isolation='READ-COMMITTED';

    事务一 事务二
    mysql> SET SESSION tx_isolation='READ-COMMITTED';
    mysql> start transaction;
    Query OK, 0 rows affected (0.00 sec)
    mysql> select * from test where code > 8;
    +----+------+
    | id | code |
    +----+------+
    | 10 | 10 |
    +----+------+
    1 row in set (0.01 sec)
    mysql> start transaction;
    Query OK, 0 rows affected (0.00 sec)
    mysql> insert into test values(9,9);
    Query OK, 1 row affected (0.00 sec)
    mysql> commit;
    Query OK, 0 rows affected (0.00 sec)
    mysql> start transaction;
    Query OK, 0 rows affected (0.00 sec)
    mysql> select * from test where code > 8;
    +----+------+
    | id | code |
    +----+------+
    | 9 | 9 |
    +----+------+
    | 10 | 10 |
    +----+------+
    1 row in set (0.01 sec)

    RC(Read Commit)隔离级别可以避免脏读，事务内无法获取其他事务未提交的变更，但是由于能够读到已经提交的事务，因此会出现幻读和不重复读。
    也就是说，RC的快照读是读取最新版本数据，而RR的快照读是读取被next-key锁作用区域的副本

    3 RR级别下能否避免幻读？

    我们先来模拟一下RR隔离级别下没有出现幻读的情况：

    开启第一个事务并执行一次快照查询。

    事务一 事务二
    mysql> start transaction;
    Query OK, 0 rows affected (0.00 sec)
    mysql> select * from test where code > 8;
    +----+------+
    | id | code |
    +----+------+
    | 10 | 10 |
    +----+------+
    1 row in set (0.01 sec)
    mysql> start transaction;
    Query OK, 0 rows affected (0.00 sec)
    mysql> insert into test values(9,9);
    Query OK, 1 row affected (0.00 sec)
    mysql> commit;
    Query OK, 0 rows affected (0.00 sec)
    mysql> start transaction;
    Query OK, 0 rows affected (0.00 sec)
    mysql> select * from test where code > 8;
    +----+------+
    | id | code |
    +----+------+
    | 10 | 10 |
    +----+------+
    1 row in set (0.01 sec)

    这两个事务的执行，有两个问题：

    1.为什么之前的例子中，在第二个事务的INSERT被阻塞了，而这次却执行成功了。
    这是因为原来的语句中带有for update，这种读取是当前读，会加锁。而本次第一个事务中的SELECT仅仅是快照读，没有加任何锁。所以不会阻塞其他的插入。

    2.数据库中的数据已经改变，为什么会读不到？
    这个就是之前提到的next-key lock锁定的副本。RC及以下级别才会读到已经提交的事务。更多的业务逻辑是希望在某段时间内或者某个特定的逻辑区间中，前后查询到的数据是一致的，当前事务是和其他事务隔离的。这也是数据库在设计实现时遵循的ACID原则。

    再给出RR条件下出现幻读的情形，这种情形不需要两个事务，一个事务就已经可以说明，

    mysql> start transaction;
Query OK, 0 rows affected (0.00 sec)

mysql> select * from test where id>8;
+----+------+
| id | code |
+----+------+
| 10 |   10 |
+----+------+
1 row in set (0.00 sec)

mysql> update test set code=9 where id=10;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

mysql> select * from test where id>8;
+----+------+
| id | code |
+----+------+
| 10 |    9 |
+----+------+
1 row in set (0.00 sec)

    至于RR隔离级别下到底会不会出现幻读，就需要看幻读的定义中的查询到底是连续的查询还是不连续的查询。如果认为RR级别下可能会出现幻读，那该级别下也会出现不重复读。

    RR隔离级别下，虽然不会出现幻读，但是会因此产生其他的问题。
    前提：当前数据表中只存在(1,1),(5,5),(10,10)三组数据。

    如果数据库隔离级别不是默认，可以执行SET SESSION tx_isolation='REPEATABLE-READ';(该语句不是全局设置)更新为RR。

    然后执行下列操作:

    事务一 事务二 备注
    mysql> start transaction;
    Query OK, 0 rows affected (0.00 sec)
    mysql> select * from test where code > 8;
    +----+------+
    | id | code |
    +----+------+
    | 10 | 10 |
    +----+------+
    1 row in set (0.01 sec)
    		 开启事务一，并查询code>8的记录，只有一条(10,10)
    mysql> start transaction;
    Query OK, 0 rows affected (0.00 sec)
    mysql> insert into test values(11,11);
    Query OK, 1 row affected (0.00 sec)
    mysql> commit;
    Query OK, 0 rows affected (0.00 sec)    		 开启第二个事务，插入(11,11)并提交
    mysql> select * from test where code > 8;
    +----+------+
    | id | code |
    +----+------+
    | 10 | 10 |
    +----+------+
    1 row in set (0.01 sec)
    		 事务一再查询一次，由于RR级别并没有读到更新
    mysql> start transaction;
    Query OK, 0 rows affected (0.00 sec)
    mysql> insert into test values(11,11);
    ERROR 1062 (23000): Duplicate entry '11' for key 'PRIMARY'    		 事务一明明没有查到，却插入不了

    4 更新丢失(Lost Update)

    4.1 更新丢失

    除了上述这类问题外，RR还会有丢失更新的问题。
    如下表给出的操作：

    事务一 事务二 备注
    mysql> start transaction;
    Query OK, 0 rows affected (0.00 sec)
    mysql> select * from test where code > 8;
    +----+------+
    | id | code |
    +----+------+
    | 10 | 10 |
    +----+------+
    1 row in set (0.01 sec)
    		 开启事务一，并查询code>8的记录，只有一条(10,10)
    mysql> start transaction;
    Query OK, 0 rows affected (0.00 sec)
    mysql> update test set id=12,code=12 where id=10;
    Query OK, 1 row affected (0.00 sec)
    Rows matched: 1 Changed: 1 Warnings: 0
    mysql> commit;
    Query OK, 0 rows affected (0.00 sec)    		 开启第二个事务，将(10,10)改为(12,12)并提交，注意这里matched是1，changed也是1
    mysql> select * from test where code > 8;
    +----+------+
    | id | code |
    +----+------+
    | 10 | 10 |
    +----+------+
    1 row in set (0.01 sec)
    		 事务一再次查询code>8的记录，仍然只有一条(10,10)
    mysql> update test set id=9,code=9 where id=10;
    Query OK, 0 row affected (0.00 sec)
    mysql> commit;
    Query OK, 0 rows affected (0.00 sec)
    Rows matched: 0 Changed: 0 Warnings: 0
    		 这里查询到0条，更新了0条

    这个例子里，事务一的更新是无效的，尽管在这个事务里程序认为还存在(10,10)记录。
    事务一中更新之前的SELECT操作是快照读，所以读到了快照里的(10,10)，而UPDATE中的WHERE子句是当前读，取得是最新版本的数据，所以matched: 0 Changed: 0。

    如果上述例子中的操作是对同一条记录做修改，就会引起更新丢失。例如，事务一和二同时开启，事务一先执行update test set code=100 where id=10;，事务二再执行update test set code=200 where id=10;，事务一的更新就会被覆盖。

    这就是经典的丢失更新问题，英文叫Lost Update，又叫提交覆盖，因为是最后执行更新的事务提交导致的覆盖。还有一种更新丢失叫做回滚覆盖，即一个事务的回滚把另一个事务提交的数据给回滚覆盖了，但是目前市面上所有的数据库都不支持这种stupid的操作，因此不再详述。

    4.2 乐观锁与悲观锁

    这种情况下，引入我们常见的两种方式来解决该问题

    • 乐观锁：在UPDATE的WHERE子句中加入版本号信息来确定修改是否生效
    • 悲观锁：在UPDATE执行前，SELECT后面加上FOR UPDATE来给记录加锁，保证记录在UPDATE前不被修改。SELECT ... FOR UPDATE是加上了X锁，也可以通过SELECT ... LOCK IN SHARE MODE加上S锁，来防止其他事务对该行的修改。

    无论是乐观锁还是悲观锁，使用的思想都是一致的，那就是当前读。乐观锁利用当前读判断是否是最新版本，悲观锁利用当前读锁定行。
    但是使用乐观锁时仍然需要非常谨慎，因为RR是可重复读的，一定不能在UPDATE之前先把版本号使用快照读获取出来。
  • 相关阅读:
    c++的socket编程 tcp
    qt下载
    定义数组类型
    虚析构函数
    运算符重载
    友元函数
    const成员函数
    静态成员变量，静态成员函数
    linux安装mysql
    智能指针
  • 原文地址：https://www.cnblogs.com/AaronCui/p/10508787.html
Copyright © 2011-2022 走看看