ITPub博客
首页 博客 专栏 学院 社区 IT新媒体评选
发博

首页 > 数据库 > MySQL > MVCC原理探究及MySQL源码实现分析

MVCC原理探究及MySQL源码实现分析

原创 MySQL 作者：沃趣科技 时间：2017-03-30 17:50:57 0 删除 编辑
沃趣科技数据库专家  董红禹


MVCC原理探究及MySQL源码实现分析
数据库多版本读场景
MVCC实现原理
通过DB_ROLL_PT 回溯查找数据历史版本
通过read view判断行记录是否可见
MVCC解决了什么问题
MySQL代码分析
InnoDB隐藏字段源码分析
InnoDB判断事务可见性源码分析


MVCC原理探究及MySQL源码实现分析

数据库多版本读场景

session 1 session 2
select a from test; return a = 10
start transaction;
update test set a = 20;
start transaction;
select a from test; return ?
commit;
select a from test; return ?

我们看下上面这个数据库日常操作的例子。

  • session 1修改了一条记录，没有提交；与此同时，session 2 来查询这条记录，这时候返回记录应该是多少呢？
  • session 1 提交之后 session 2 查询出来的又应该是多少呢？

由于MySQL支持多种隔离级别，这个问题是需要看session2的事务隔离级别的，情况如下:

  • 隔离级别为 READ-UNCOMMITTED 情况下: 
    session 1 commit前后 session 2 去查看都会看到的是修改后的结果 a = 20
  • 隔离级别为 READ-COMMITTED 情况下: 
    session 1 commit 前查看到的还是 a =10 , commit之后看到的是 a = 20
  • 隔离级别为 REPEATABLE-READ， SERIALIZABLE 情况下: 
    session 1 commit前后 session 2 去查看都会看到的是修改后的结果 a = 10

其实不管隔离级别，我们也抛开数据库中的ACID，我们思考一个问题：众所周知，InnoDB的数据都是存储在B-tree里面的，修改后的数据到底要不要存储在实际的B-tree叶子节点，session2是怎么做到查询出来的结果还是10，而不是20呢？

MVCC实现原理

上述现象在数据库中大家经常看到，但是数据库到底是怎么实现的，深究的人就不多了。 
其实原理很简单，数据库就是通过UNDO和MVCC来实现的。

通过DB_ROLL_PT 回溯查找数据历史版本

  • 首先InnoDB每一行数据还有一个DB_ROLL_PT的回滚指针，用于指向该行修改前的上一个历史版本 

    当插入的是一条新数据时，记录上对应的回滚段指针为NULL


更新记录时，原记录将被放入到undo表空间中，并通过DB_ROLL_PT指向该记录。session2查询返回的未修改数据就是从这个undo中返回的。MySQL就是根据记录上的回滚段指针及事务ID判断记录是否可见，如果不可见继续按照DB_ROLL_PT继续回溯查找。

通过read view判断行记录是否可见

具体的判断流程如下:

  • RR隔离级别下，在每个事务开始的时候，会将当前系统中的所有的活跃事务拷贝到一个列表中(read view)
  • RC隔离级别下，在每个语句开始的时候，会将当前系统中的所有的活跃事务拷贝到一个列表中(read view) 
    并按照以下逻辑判断事务的可见性。 

MVCC解决了什么问题

  • MVCC使得数据库读不会对数据加锁，select不会加锁，提高了数据库的并发处理能力
  • 借助MVCC，数据库可以实现RC，RR等隔离级别，用户可以查看当前数据的前一个或者前几个历史版本。保证了ACID中的I-隔离性。

MySQL代码分析

前面我们介绍了什么是MVCC，以及它解决了什么问题。 
下面我们来看一下在MySQL源码中，到底是怎么实现这个逻辑的。

InnoDB隐藏字段源码分析

InnoDB表中会存有三个隐藏字段，这三个字段是mysql默认帮我们添加的。我们可以通过代码中查看到: 

    
	
	
  1. 
		dict_table_add_system_columns(
	
    2. 

	
  2. 
		/*==========================*/
	
    3. 

	
  3. 
		dict_table_t* table, /*!< in/out: table */
	
    4. 

	
  4. 
		mem_heap_t* heap) /*!< in: temporary heap */
	
    5. 

	
  5. 
		{
	
    6. 

	
  6. 
		ut_ad(table);
	
    7. 

	
  7. 
		ut_ad(table->n_def == (table->n_cols - table->get_n_sys_cols()));
	
    8. 

	
  8. 
		ut_ad(table->magic_n == DICT_TABLE_MAGIC_N);
	
    9. 

	
  9. 
		ut_ad(!table->cached);
	
    10. 

	
  10. 
		
	
    11. 

	
  11. 
		/* NOTE: the system columns MUST be added in the following order
	
    12. 

	
  12. 
		(so that they can be indexed by the numerical value of DATA_ROW_ID,
	
    13. 

	
  13. 
		etc.) and as the last columns of the table memory object.
	
    14. 

	
  14. 
		The clustered index will not always physically contain all system
	
    15. 

	
  15. 
		columns.
	
    16. 

	
  16. 
		Intrinsic table don't need DB_ROLL_PTR as UNDO logging is turned off
	
    17. 

	
  17. 
		for these tables. */
	
    18. 

	
  18. 
		
	
    19. 

	
  19. 
		dict_mem_table_add_col(table, heap, "DB_ROW_ID", DATA_SYS,
	
    20. 

	
  20. 
		 DATA_ROW_ID | DATA_NOT_NULL,
	
    21. 

	
  21. 
		 DATA_ROW_ID_LEN);
	
    22. 

	
  22. 
		
	
    23. 

	
  23. 
		#if (DATA_ITT_N_SYS_COLS != 2)
	
    24. 

	
  24. 
		#error "DATA_ITT_N_SYS_COLS != 2"
	
    25. 

	
  25. 
		#endif
	
    26. 

	
  26. 
		
	
    27. 

	
  27. 
		#if DATA_ROW_ID != 0
	
    28. 

	
  28. 
		#error "DATA_ROW_ID != 0"
	
    29. 

	
  29. 
		#endif
	
    30. 

	
  30. 
		dict_mem_table_add_col(table, heap, "DB_TRX_ID", DATA_SYS,
	
    31. 

	
  31. 
		 DATA_TRX_ID | DATA_NOT_NULL,
	
    32. 

	
  32. 
		 DATA_TRX_ID_LEN);
	
    33. 

	
  33. 
		#if DATA_TRX_ID != 1
	
    34. 

	
  34. 
		#error "DATA_TRX_ID != 1"
	
    35. 

	
  35. 
		#endif
	
    36. 

	
  36. 
		
	
    37. 

	
  37. 
		if (!table->is_intrinsic()) {
	
    38. 

	
  38. 
		dict_mem_table_add_col(table, heap, "DB_ROLL_PTR", DATA_SYS,
	
    39. 

	
  39. 
		 DATA_ROLL_PTR | DATA_NOT_NULL,
	
    40. 

	
  40. 
		 DATA_ROLL_PTR_LEN);
	
    41. 

	
  41. 
		#if DATA_ROLL_PTR != 2
	
    42. 

	
  42. 
		#error "DATA_ROLL_PTR != 2"
	
    43. 

	
  43. 
		#endif
	
    44. 

	
  44. 
		
	
    45. 

	
  45. 
		/* This check reminds that if a new system column is added to
	
    46. 

	
  46. 
		the program, it should be dealt with here */
	
    47. 

	
  47. 
		#if DATA_N_SYS_COLS != 3
	
    48. 

	
  48. 
		#error "DATA_N_SYS_COLS != 3"
	
    49. 

	
  49. 
		#endif
	
    50. 

	
  50. 
		}
	
    51. 

	
  51. 
		}
	
    52.
  • DB_ROW_ID:如果表中没有显示定义主键或者没有唯一索引则MySQL会自动创建一个6字节的row id存在记录中
  • DB_TRX_ID:事务ID
  • DB_ROLL_PTR:回滚段指针

InnoDB判断事务可见性源码分析

mysql中并不是根据事务的事务ID进行比较判断记录是否可见，而是根据每一行记录上的事务ID进行比较来判断记录是否可见。

我们可以通过实验验证 ， 创建一张表里面插入一条记录 

    
	
	
  1. 
		dhy@10.16.70.190:3306 12:25:47 [dhy]>select * from dhytest;
	
    2. 

	
  2. 
		+------+
	
    3. 

	
  3. 
		| id |
	
    4. 

	
  4. 
		+------+
	
    5. 

	
  5. 
		| 10 |
	
    6. 

	
  6. 
		+------+
	
    7. 

	
  7. 
		1 row in set (7.99 sec)
	
    8.

手工开启一个事务 更新一条记录 但是并不提交: 

    
	
	
  1. 
		dhy@10.10.80.199:3306 15:28:24 [dhy]>update dhytest set id = 20;
	
    2. 

	
  2. 
		Query OK, 3 rows affected (40.71 sec)
	
    3. 

	
  3. 
		Rows matched: 3 Changed: 3 Warnings: 0
	
    4.

在另外一个会话执行查询 

    
	
	
  1. 
		dhy@10.16.70.190:3306 12:38:33 [dhy]>select * from dhytest;
	
    2.

这时我们可以跟踪调试mysql 查看他是怎么判断记录的看见性，中间函数调用太多列举最重要部分

这里需要介绍一个重要的类 ReadView,Read View是事务开启时当前所有事务的一个集合,这个类中存储了当前Read View中最大事务ID及最小事务ID 

    
	
	
  1. 
		/** The read should not see any transaction with trx id >= this
	
    2. 

	
  2. 
		value. In other words, this is the "high water mark". */
	
    3. 

	
  3. 
		trx_id_t m_low_limit_id;
	
    4. 

	
  4. 
		
	
    5. 

	
  5. 
		/** The read should see all trx ids which are strictly
	
    6. 

	
  6. 
		smaller (<) than this value.  In other words, this is the
	
    7. 

	
  7. 
		low water mark". */
	
    8. 

	
  8. 
		trx_id_t m_up_limit_id;
	
    9. 

	
  9. 
		
	
    10. 

	
  10. 
		/** trx id of creating transaction, set to TRX_ID_MAX for free
	
    11. 

	
  11. 
		views. */
	
    12. 

	
  12. 
		trx_id_t m_creator_trx_id;
	
    13. 

	
  13. 
		
	
    14.

当我们执行上面的查询语句时,跟踪到主要函数如下: 

    
	
	
  1. 
		函数row_search_mvcc->lock_clust_rec_cons_read_sees
	
    2. 

	
  2. 
		bool
	
    3. 

	
  3. 
		lock_clust_rec_cons_read_sees(
	
    4. 

	
  4. 
		/*==========================*/
	
    5. 

	
  5. 
		const rec_t* rec, /*!< in: user record which should be read or
	
    6. 

	
  6. 
		passed over by a read cursor */
	
    7. 

	
  7. 
		dict_index_t* index, /*!< in: clustered index */
	
    8. 

	
  8. 
		const ulint* offsets,/*!< in: rec_get_offsets(rec, index) */
	
    9. 

	
  9. 
		ReadView* view) /*!< in: consistent read view */
	
    10. 

	
  10. 
		{
	
    11. 

	
  11. 
		ut_ad(index->is_clustered());
	
    12. 

	
  12. 
		ut_ad(page_rec_is_user_rec(rec));
	
    13. 

	
  13. 
		ut_ad(rec_offs_validate(rec, index, offsets));
	
    14. 

	
  14. 
		
	
    15. 

	
  15. 
		/* Temp-tables are not shared across connections and multiple
	
    16. 

	
  16. 
		transactions from different connections cannot simultaneously
	
    17. 

	
  17. 
		operate on same temp-table and so read of temp-table is
	
    18. 

	
  18. 
		always consistent read. */
	
    19. 

	
  19. 
		//只读事务或者临时表是不需要一致性读的判断
	
    20. 

	
  20. 
		if (srv_read_only_mode || index->table->is_temporary()) {
	
    21. 

	
  21. 
		ut_ad(view == 0 || index->table->is_temporary());
	
    22. 

	
  22. 
		return(true);
	
    23. 

	
  23. 
		}
	
    24. 

	
  24. 
		
	
    25. 

	
  25. 
		/* NOTE that we call this function while holding the search
	
    26. 

	
  26. 
		system latch. */
	
    27. 

	
  27. 
		
	
    28. 

	
  28. 
		trx_id_t trx_id = row_get_rec_trx_id(rec, index, offsets); //获取记录上的TRX_ID这里需要解释下，我们一个查询可能满足的记录数有多个。那我们每读取一条记录的时候就要根据这条记录上的TRX_ID判断这条记录是否可见
	
    29. 

	
  29. 
		return(view->changes_visible(trx_id, index->table->name)); //判断记录可见性
	
    30. 

	
  30. 
		}
	
    31.

下面是真正判断记录的看见性。 

    
	
	
  1. 
		bool changes_visible(
	
    2. 

	
  2. 
		trx_id_t id,
	
    3. 

	
  3. 
		const table_name_t& name) const
	
    4. 

	
  4. 
		MY_ATTRIBUTE((warn_unused_result))
	
    5. 

	
  5. 
		{
	
    6. 

	
  6. 
		ut_ad(id > 0);
	
    7. 

	
  7. 
		
	
    8. 

	
  8. 
		//如果ID小于Read View中最小的, 则这条记录是可以看到。说明这条记录是在select这个事务开始之前就结束的
	
    9. 

	
  9. 
		if (id < m_up_limit_id || id == m_creator_trx_id) {
	
    10. 

	
  10. 
		
	
    11. 

	
  11. 
		return(true);
	
    12. 

	
  12. 
		}
	
    13. 

	
  13. 
		
	
    14. 

	
  14. 
		check_trx_id_sanity(id, name);
	
    15. 

	
  15. 
		
	
    16. 

	
  16. 
		//如果比Read View中最大的还要大，则说明这条记录是在事务开始之后进行修改的，所以此条记录不应查看到
	
    17. 

	
  17. 
		if (id >= m_low_limit_id) {
	
    18. 

	
  18. 
		
	
    19. 

	
  19. 
		return(false);
	
    20. 

	
  20. 
		
	
    21. 

	
  21. 
		} else if (m_ids.empty()) {
	
    22. 

	
  22. 
		
	
    23. 

	
  23. 
		return(true);
	
    24. 

	
  24. 
		}
	
    25. 

	
  25. 
		
	
    26. 

	
  26. 
		const ids_t::value_type* p = m_ids.data();
	
    27. 

	
  27. 
		
	
    28. 

	
  28. 
		return(!std::binary_search(p, p + m_ids.size(), id)); //判断是否在Read View中， 如果在说明在创建Read View时 此条记录还处于活跃状态则不应该查询到，否则说明创建Read View是此条记录已经是不活跃状态则可以查询到
	
    29. 

	
  29. 
		}
	
    30.

对于不可见的记录都是通过row_vers_build_for_consistent_read函数查询UNDO构建老版本记录，直到记录可见。

这里需要说明一点 不同的事务隔离级别，可见性的实现也不一样:

  • READ-COMMITTED 
    事务内的每个查询语句都会重新创建Read View，这样就会产生不可重复读现象发生
  • REPEATABLE-READ 
    事务内开始时创建Read View ， 在事务结束这段时间内 每一次查询都不会重新重建Read View ， 从而实现了可重复读。

参考资料: 
《唐成－2016PG大会-数据库多版本实现内幕.pdf》

来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/28218939/viewspace-2136363/ ，如需转载，请注明出处，否则将追究法律责任。

0
0
上一篇： ASM 翻译系列第四十弹：理解ASM中 REQUIRED_MIRROR_FREE_MB和USABLE_FILE_MB的含义
下一篇： Oracle数据库性能障碍分析利器：SYSTEMSTATE DUMP介绍
请登录后发表评论 登录
全部评论
沃趣科技
专家姓名：沃趣科技
杭州沃趣科技股份有限公司创建于2012年（股票代码：839849），是一家专注为企业用户提供基于高性能、高可用、可扩展的开放数据库云平台解决方案的国产厂商。公司创始团队为原阿里巴巴数据库技术团队核心骨干，凭借丰富的研发及运维经验，为行业客户提供数据库云产品及软硬件一体化解决方案。

注册时间：2016-07-18

  • 博文量
    290
  • 访问量
    994545

最新文章

支持我们 作者招募 用户协议 FAQ Contact Us

北京盛拓优讯信息技术有限公司. 版权所有  京ICP备16024965号-8 北京市公安局海淀分局网监中心备案编号：11010802021510 niuxiaotong@pcpop.com 17352615567 未成年人举报专区

广播电视节目制作经营许可证(京) 字第1234号 中国互联网协会会员

违法和不良信息举报电话:18101376593