一致性读的秘密（innobase note -- read)

justlooks

首先是来自手册的一致性读的定义：
A consistent read means that InnoDB uses multi-versioning to present to a query a snapshot of the database at a point in time
一致读就是innodb使用MVCC机制把数据库某一点的快照提供给一个查询
The query sees the changes made by transactions that committed before that point of time, and no changes made by later or uncommitted transactions.
该查询能够看到在这个点之前提交的事务所做的所有改变，但是看不到之后开始的事务，或者是在这个时间点还未提交的事务所做的改变

innobase使用read view来实现这个一致读，read view和trx是紧密联系的，通过view_list域把自己连到trx_sys上，而每个read view都有个创建它的trx，用creator_trx_id字段标记
来看下read view的数据结构

1. 
   
2. struct read_view_struct{
   
3.          ulint   type;
   
4.          dulint  undo_no;
   
5.          dulint  low_limit_no;         #这个不是很清楚
   
6.          dulint  low_limit_id;
   
7.          dulint  up_limit_id;
   
8.          ulint   n_trx_ids;
   
9.          dulint* trx_ids;
   
10.          dulint  creator_trx_id;
    
11.          UT_LIST_NODE_T(read_view_t) view_list;
    
12. }
    

复制代码

那么从read view的创建代码(read_view_open_now调用）并结合定义来分析以上字段的意义

1. 
   
2. #首先会在trx_sys系统结构中统计所有当前没有提交的事务
   
3. view = read_view_create_low(UT_LIST_GET_LEN(trx_sys->trx_list), heap)
   
4. #那么对于该view创建点之后的新事务，该read view是无法看到其数据变化的，read view用low_limit_id来标记这个时间点，也就是说凡是trx id超过这个值的就属于将来的事务
   
5. view->low_limit_no = trx_sys->max_trx_id;
   
6. view->low_limit_id = view->low_limit_no;
   
7. #那么自然所有这个创建时间中活跃的事务也是无法被该view看到的，除了read view的创建者（注意这个例外，会导致奇怪的现象）
   
8. n = 0;
   
9. trx = UT_LIST_GET_FIRST(trx_sys->trx_list);
   
10. while (trx) {
    
11.         if (ut_dulint_cmp(trx->id, cr_trx_id) != 0
    
12.                            && (trx->conc_state == TRX_ACTIVE
    
13.                            || trx->conc_state == TRX_PREPARED)) {
    
14. .......
    
15.       trx = UT_LIST_GET_NEXT(trx_list, trx);
    
16. }
    
17. #而如何描述过去呢？read view用up_limit_id描述过去，也就是当trx id小于这个值都是过去commit的事务
    
18. if (n > 0) {
    
19.         view->up_limit_id = read_view_get_nth_trx_id(view, n - 1);  #因为这个数组是来自trx list的，而trx list是开头是最新的事务，所以这个就是最老的未commit的事务
    
20.        } else {
    
21.           view->up_limit_id = view->low_limit_id;
    
22.      }
    
23. #VIEW list也是从新到旧排列的
    
24. UT_LIST_ADD_FIRST(view_list, trx_sys->view_list, view);
    

复制代码

下面是一致读的判定代码，对照上面的说明应该很清楚了，在read_view_sees_trx_id调用中

1. 
   
2.    if (ut_dulint_cmp(trx_id, view->up_limit_id) < 0) {
   
3. 
   
4.                 return(TRUE);
   
5.         }
   
6. 
   
7.         if (ut_dulint_cmp(trx_id, view->low_limit_id) >= 0) {
   
8. 
   
9.                 return(FALSE);
   
10.         }
    
11. 
    
12.         n_ids = view->n_trx_ids;
    
13. 
    
14.         for (i = 0; i < n_ids; i++) {
    
15. 
    
16.                 cmp = ut_dulint_cmp(
    
17.                         trx_id,
    
18.                         read_view_get_nth_trx_id(view, n_ids - i - 1));
    
19.                 if (cmp <= 0) {
    
20.                         return(cmp < 0);
    
21.                 }
    
22.         }
    
23. 
    
24.         return(TRUE);
    

复制代码

那么再来看下上面提到的奇怪的现象，先来看演示

mysql> show create table t1\G
*************************** 1. row ***************************
       Table: t1
Create Table: CREATE TABLE `t1` (
  `id` int(11) NOT NULL,
  `name` char(10) default NULL,
  PRIMARY KEY  (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1

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

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

mysql> update t1 set id=id+200 where name='bbb';
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

S1
mysql> select * from t1;
+----+------+
| id | name |
+----+------+
|  1 | aaa  |
| 22 | bbb  |
+----+------+
2 rows in set (0.00 sec)

S2
mysql> commit;
Query OK, 0 rows affected (0.04 sec)


S1
mysql> update t1 set id=id+20 where name='bbb';
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

mysql> select * from t1;
+-----+------+
| id  | name |
+-----+------+
|   1 | aaa  |
|  22 | bbb  |
| 242 | bbb  |
+-----+------+
3 rows in set (0.00 sec)

renxiao2003

学习。谢谢分享。

yejr

回复 1# justlooks

使用了什么隔离级别？

justlooks

回复 3# yejr


    默认的，也就是可重复读

justlooks

你试下就知道了，关于这个手册上有提到，在一致读章节

cenalulu

同觉得不可能

ruochen

我在5.5.4-m3上测试没发现,RR隔离级别


LZ的帖子中有点奇怪，一个简单的update在你的机器上跑了11.22 sec???
-------------------------------------------------
Query OK, 1 row affected (11.22 sec)
-------------------------------------------------


LZ把版本（mysql & innodb）和时间戳都加上，再测试一遍看看

justlooks

我在5.5.4-m3上测试没发现,RR隔离级别


LZ的帖子中有点奇怪，一个简单的update在你的机器上跑了11.22 s ...
ruochen 发表于 2010-08-26 12:13

    那个是因为session 1 没有commit导致了这个update被block。

另外抱歉我的演示过程写错了，为什么你们按我的演示过程无法出我的结果呢，因为我session 2 忘记首先select了，那么如果第1次不select就不会从undo log中建立先前的版本，我改正了下你们再看看

这个结果是一致读本身的机制导致的，结果并不会因为MYSQL的版本不同而不同

ruochen

我在5.5.4-m3上演示了，存在LZ所说的事实

S1
mysql> update t1 set id=id+20 where name='bbb';
这里S1没有commit

RR隔离级别是存在幻读的

justlooks

回复 9# ruochen


    我觉得这个不应该是phantom read,我理解的phantom read是重复执行同一条查询会得到前后不一致的情况，而演示中2个select中间插了个update,那么就应该不是phantom read