幻读phantom rows
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 语句执行了两次，但是在第二次返回了第一次没有返回的行,那么这些行就是“phantom” row.
read view(或者说 mvcc)实现了一致性不锁定读(consistent nonlocking reads)，从而避免了(非当前读下)幻读
实验1:
开两个窗口设置
set session tx_isolation='repeatable-read';
select @@session.autocommit;select @@global.tx_isolation,@@session.tx_isolation;
create table read_view(text varchar(50));
insert into read_view values('init');
两个会话开始事务
session_a>begin;
query ok, 0 rows affected (0.00 sec)
session_b>begin;
query ok, 0 rows affected (0.00 sec)
session_a执行一个查询，这个查询可以访问任何表，这个查询的目的是创建一个当前时间点的快照
start transaction with consistent snapshot;也可以达到同样的效果
session_a>select * from dept;
-------- ------------ ----------
| deptno | dname | loc |
-------- ------------ ----------
| 10 | accounting | new york |
| 20 | research | dallas |
| 30 | sales | chicago |
| 40 | operations | boston |
-------- ------------ ----------
4 rows in set (0.00 sec)
session_b 插入一条记录并提交
session_b>insert into read_view values('after session a select');
query ok, 1 row affected (0.01 sec)
session_b>commit;
query ok, 0 rows affected (0.00 sec)
session_a
session_a>select * from read_view;
------
| text |
------
| init |
------
1 row in set (0.00 sec)
session_a>commit;
query ok, 0 rows affected (0.00 sec)
session_a>select * from read_view;
------------------------
| text |
------------------------
| init |
| after session a select |
------------------------
2 rows in set (0.00 sec)
由于 session_a 第一次的查询开始于 session_b 插入数据前，所以创建了一个以select操作的时间为基准点的 read view,避免了幻读的产生
所以在 session_a 的事务结束前,无法看到 session_b 对表 read_view 做出的任何更改 (insert,delete,update)
实验2
两个会话开始事务
session_a>begin;
query ok, 0 rows affected (0.00 sec)
session_b>begin;
query ok, 0 rows affected (0.00 sec)
session_b 在 session_a 创建read view 前插入数据
session_b>insert into read_view values('before session_a select');
query ok, 1 row affected (0.00 sec)
session_b>commit;
query ok, 0 rows affected (0.00 sec)
session_a
session_a>select * from read_view;
-------------------------
| text |
-------------------------
| init |
| after session a select |
| before session_a select |
-------------------------
3 rows in set (0.00 sec)
session_a>commit
-> ;
query ok, 0 rows affected (0.00 sec)
session_a>select * from read_view;
-------------------------
| text |
-------------------------
| init |
| after session a select |
| before session_a select |
-------------------------
3 rows in set (0.00 sec)
由于 session_a 第一次查询开始于 session_b 对表做出更改并提交后,所以这次的 read view 包含了 session_b 所做出的更改
在官方文档中写道
http://dev.mysql.com/doc/refman/5.7/en/innodb-consistent-read.html
a consistent read means that innodb uses multi-versioning to present to a query a snapshot of the database at a point in time. the query sees the changes made by transactions that committed before that point of time, and no changes made by later or uncommitted transactions. the exception to this rule is that the query sees the changes made by earlier statements within the same transaction. this exception causes the following anomaly: if you update some rows in a table, a select sees the latest version of the updated rows, but it might also see older versions of any rows. if other sessions simultaneously update the same table, the anomaly means that you might see the table in a state that never existed in the database.
一致性读是通过 mvcc 为查询提供了一个基于时间的点的快照。这个查询只能看到在自己之前提交的数据，而在查询开始之后提交的数据是不可以看到的。一个特例是,这个查询可以看到于自己开始之后的同一个事务产生的变化。这个特例会产生一些反常的现象
if the transaction isolation level is repeatable read (the default level), all consistent reads within the same transaction read the snapshot established by the first such read in that transaction. you can get a fresher snapshot for your queries by committing the current transaction and after that issuing new queries.
在默认隔离级别repeatable read下，同一事务的所有一致性读只会读取第一次查询时创建的快照
实验3
两个会话开始事务
session_a开始事务并创建快照
session_a>start transaction with consistent snapshot;
query ok, 0 rows affected (0.00 sec)
session_b>begin;
query ok, 0 rows affected (0.00 sec)
session_a>select * from read_view;
-------------------------
| text |
-------------------------
| init |
| after session a select |
| before session_a select |
-------------------------
3 rows in set (0.00 sec)
session_b>insert into read_view values('anomaly'),('anomaly');
query ok, 2 rows affected (0.00 sec)
records: 2 duplicates: 0 warnings: 0
session_b>update read_view set text='init' where text='init';
query ok, 1 row affected (0.00 sec)
rows matched: 1 changed: 1 warnings: 0
session_b>commit;
query ok, 0 rows affected (0.00 sec)
session_a>select * from read_view;
-------------------------
| text |
-------------------------
| init |
| after session a select |
| before session_a select |
-------------------------
3 rows in set (0.00 sec)
session_a更新了它并没有"看"到的行
session_a>update read_view set text='anomaly!' where text='anomaly';
query ok, 2 rows affected (0.00 sec)
rows matched: 2 changed: 2 warnings: 0
session_a>select * from read_view;
-------------------------
| text |
-------------------------
| init |
| after session a select |
| before session_a select |
| anomaly! |
| anomaly! |
-------------------------
5 rows in set (0.00 sec)
session_a>commit;
query ok, 0 rows affected (0.00 sec)
session_a>select * from read_view;
-------------------------
| text |
-------------------------
| init |
| after session a select |
| before session_a select |
| anomaly! |
| anomaly! |
-------------------------
5 rows in set (0.00 sec)
观察实验步骤可以发现，在倒数第二次查询中，出现了一个并不存在的状态
the anomaly means that you might see the table in a state that never existed in the database
这里a的前后两次读，均为快照读，而且是在同一个事务中。但是b先插入直接提交，此时a再update，update属于当前读，所以可以作用于新插入的行，并且将修改行的当前版本号设为a的事务号，所以第二次的快照读，是可以读取到的，因为同事务号。这种情况符合mvcc的规则，如果要称为一种幻读也非不可，算为一个特殊情况来看待吧。
with read committed isolation level, each consistent read within a transaction sets and reads its own fresh snapshot.
在 read commit 隔离级别下，同一事务的每个一致性读sets and reads its own fresh snapshot.
实验4
修改事务隔离级别
set session tx_isolation='read-committed'
两个会话开始事务
session_a>begin;
query ok, 0 rows affected (0.00 sec)
session_b>begin;
query ok, 0 rows affected (0.00 sec)
session_a>select * from read_view;
-------------------------
| text |
-------------------------
| init |
| after session a select |
| before session_a select |
| anomaly! |
| anomaly! |
-------------------------
5 rows in set (0.00 sec)
session_b>insert into read_view values('hehe');
query ok, 1 row affected (0.00 sec)
session_b>commit;
query ok, 0 rows affected (0.00 sec)
session_a>select * from read_view;
-------------------------
| text |
-------------------------
| init |
| after session a select |
| before session_a select |
| anomaly! |
| anomaly! |
| hehe |
-------------------------
6 rows in set (0.00 sec)
read commit 每次读取都是新的快照
innodb通过nextkey lock解决了当前读时的幻读问题
innodb行锁分为:
| 类型 | 说明 |
|---|---|
| record lock: | 在索引上对单行记录加锁. |
| gap lock: | 锁定一个范围的记录,但不包括记录本身.锁加在未使用的空闲空间上,可能是两个索引记录之间，也可能是第一个索引记录之前或最后一个索引之后的空间. |
| next-key lock: | 行锁与间隙锁组合起来用就叫做next-key lock。锁定一个范围，并且锁定记录本身。对于行的查询，都是采用该方法，主要目的是解决幻读的问题。 |
实验5
创建表
(mysql@localhost) [fandb]> create table t5(id int,key(id));
query ok, 0 rows affected (0.02 sec)
session_a>insert into t5 values(1),(4),(7),(10);
query ok, 4 rows affected (0.00 sec)
records: 4 duplicates: 0 warnings: 0
开始实验
session_a>begin;
query ok, 0 rows affected (0.00 sec)
session_a>select * from t5;
------
| id |
------
| 1 |
| 4 |
| 7 |
| 10 |
------
4 rows in set (0.00 sec)
session_a>select * from t5 where id=7 for update;
------
| id |
------
| 7 |
------
1 row in set (0.00 sec)
session_b>begin;
query ok, 0 rows affected (0.00 sec)
session_b>insert into t5 values(2);
query ok, 1 row affected (0.00 sec)
session_b>insert into t5 values(12);
query ok, 1 row affected (0.00 sec)
session_b>insert into t5 values(5); --被阻塞
^cctrl-c -- sending "kill query 93" to server ...
ctrl-c -- query aborted.
^[[aerror 1317 (70100): query execution was interrupted
session_b>insert into t5 values(7); --被阻塞
^cctrl-c -- sending "kill query 93" to server ...
ctrl-c -- query aborted.
error 1317 (70100): query execution was interrupted
session_b>insert into t5 values(9); --被阻塞
^cctrl-c -- sending "kill query 93" to server ...
ctrl-c -- query aborted.
error 1317 (70100): query execution was interrupted
session_b>commit;
query ok, 0 rows affected (0.00 sec)
session_a>select * from t5;
------
| id |
------
| 1 |
| 4 |
| 7 |
| 10 |
------
4 rows in set (0.00 sec)
session_a>commit;
query ok, 0 rows affected (0.00 sec)
session_a>select * from t5;
------
| id |
------
| 1 |
| 2 |
| 4 |
| 7 |
| 10 |
| 12 |
------
6 rows in set (0.00 sec)
当以当前读模式select * from t5 where id=7 for update;获取 id=7的数据时,产生了 next-key lock,锁住了4-10范围和 id=7单个record
从而阻塞了 session_b在这个范围内插入数据，而在除此之外的范围内是可以插入数据的。
在倒数第二个查询中,因为 read view 的存在，避免了我们看到 2和12两条数据，避免了幻读
同时因为 next-key lock 的存在,阻塞了其他回话插入数据，因此当前模式读不会产生幻读(select for update 是以当前读模式获取数据)
###尽量使用唯一索引,因为唯一索引会把next-key lock降级为record lock
实验6
创建表
(mysql@localhost) [fandb]> create table t6(id int primary key);
query ok, 0 rows affected (0.02 sec)
session_a>insert into t6 values(1),(4),(7),(10);
query ok, 4 rows affected (0.00 sec)
records: 4 duplicates: 0 warnings: 0
开始实验
session_a>begin;
query ok, 0 rows affected (0.00 sec)
session_a>select * from t6;
----
| id |
----
| 1 |
| 4 |
| 7 |
| 10 |
----
4 rows in set (0.00 sec)
session_a>select * from t6 where id=7 for update;
----
| id |
----
| 7 |
----
1 row in set (0.00 sec)
session_b>begin;
query ok, 0 rows affected (0.00 sec)
session_b>insert into t6 values(5); --插入成功没有阻塞
query ok, 1 row affected (0.00 sec)
session_b>insert into t6 values(8); --插入成功没有阻塞
query ok, 1 row affected (0.00 sec)
session_b>commit;
query ok, 0 rows affected (0.00 sec)
session_a>select * from t6;
----
| id |
----
| 1 |
| 4 |
| 7 |
| 10 |
----
4 rows in set (0.00 sec)
session_a>commit;
query ok, 0 rows affected (0.00 sec)
session_a>select * from t6;
----
| id |
----
| 1 |
| 4 |
| 5 |
| 7 |
| 8 |
| 10 |
----
6 rows in set (0.00 sec)
当 id 列有唯一索引,next-key lock 会降级为 records lock