初探InnoDB MVCC源码实现

1. 背景

本文基于MySQL InnoDB源码对InnoDB中非锁定一致性读是如何实现的作一些简单的探究。

2. 基本概念

2.1 隐藏字段

在经典之作《高性能MySQL》的1.4节中提及了MySQL中MVCC的实现,原著中提及了

InnoDB implements MVCC by storing with each row two additional, hidden values that record when the row was created and when it was expired (or deleted). Rather than storing the actual times at which these events occurred, the row stores the system version number at the time each event occurred. This is a number that increments each time a transaction begins. Each transaction keeps its own record of the current system version, as of the time it began. Each query has to check each row’s version numbers against the transaction’s version.

我们知道InnoDB中聚簇索引包含了数据行的完整信息,《高性能MySQL》这里说的就是在InnoDB的聚簇索引中的行包含了行记录何时被创建以及何时被删除的信息。《高性能MySQL》这里的描述或许是为了方便读者理解。实际上聚簇索引中的行包含了这么几个隐藏的字段信息:

  • DATA_ROW_ID 6字节 内部存储的单调递增的行id
  • DATA_TRX_ID 6字节 最新一个对某记录增删改的事务id
  • DATA_ROLL_PTR 7字节 回滚段指针

关于这里信息可以参考storage/innobase/include/data0type.h头文件。

而对于二级索引记录,是不包含上面这几个隐藏信息的,但对于二级索引,会在页中会记录一个PAGE_MAX_TRX_ID,表示对该页数据修改过的最大事务id。

关于这里的信息可以参考storage/innobase/include/page0page.h头文件

2.2 Read View

Read View用来判断某个一致性读是否可见其它事务对表的修改。

Read View被定义在read0types.h头文件中,下面来看一下其中部分字段:

// 事务id>=m_low_limit_id的修改对于当前读不可见
trx_id_t    m_low_limit_id;

// 事务id<m_up_limit_id的修改对于当前读可见
trx_id_t    m_up_limit_id;

// 创建view的事务id
trx_id_t    m_creator_trx_id;

// 创建view时处于active状态的读写事务列表,这里的ids_t可以简单看作是一个vector
ids_t       m_ids;

在InnoDB的事务定义(参考trx0trx.h头文件)中包含了一个字段用来表示该事务的Read View。

ReadView*   read_view;

在InnoDB进行进行一致性读时,会判断当前事务的Read View是否存在,如果不存在则get一个新的Read View(InnoDB对于Read View有复用的机制,所以如果不存在可以复用的Read View对象才会去显示地new一个新的出来)。下面是trx_assign_read_view方法实现:

ReadView*
trx_assign_read_view(
/*=================*/
    trx_t*      trx)    /*!< in/out: active transaction */
{
    ut_ad(trx->state == TRX_STATE_ACTIVE);

    if (srv_read_only_mode) {

        ut_ad(trx->read_view == NULL);
        return(NULL);

    } else if (!MVCC::is_view_active(trx->read_view)) {
        trx_sys->mvcc->view_open(trx->read_view, trx);
    }

    return(trx->read_view);
}

下面再来看一下Read View是如何初始化的。

void
ReadView::prepare(trx_id_t id)
{
    ut_ad(mutex_own(&trx_sys->mutex));

    m_creator_trx_id = id;

    // trx_sys->max_trx_id是当前最小未分配的事务id。
    m_low_limit_no = m_low_limit_id = trx_sys->max_trx_id;

    // 将当前只读事务的id拷贝到view中的m_ids。
    if (!trx_sys->rw_trx_ids.empty()) {
        copy_trx_ids(trx_sys->rw_trx_ids);
    } else {
        m_ids.clear();
    }

    // trx_sys->serialisation_list是事务提交时会加入的一个按照trx->no排序的列表。
    // 这里取列表中第一个(如果有的话)为m_low_limit_no供purge线程作为是否清理undo的依据。
    if (UT_LIST_GET_LEN(trx_sys->serialisation_list) > 0) {
        const trx_t*    trx;

        trx = UT_LIST_GET_FIRST(trx_sys->serialisation_list);

        if (trx->no < m_low_limit_no) {
            m_low_limit_no = trx->no;
        }
    }
}

void
ReadView::complete()
{
    // m_up_limit_id取活跃事务最小id。
    m_up_limit_id = !m_ids.empty() ? m_ids.front() : m_low_limit_id;

    ut_ad(m_up_limit_id <= m_low_limit_id);

    m_closed = false;
}

对于Read Committed的隔离级别,在一致性读语句结束后,会关闭掉Read View,而对于Repeatable Read的隔离级别,Read View在创建后会一直到事务结束时才被关闭。

3 Read View如何判断可见性

上面已经对Read View进行了大致介绍,下面就来看一下InnoDB是如何判断记录是否对当前事务可见的吧。这里的入口是storage/innobase/row/row0sel.ccrow_search_mvcc方法。

3.1 走聚簇索引的情况

假设sql查询走的是聚簇索引,则通过下面的lock_clust_rec_cons_read_sees方法来判断记录rec是否对当前事务可见。

bool
lock_clust_rec_cons_read_sees(
    const rec_t*    rec,
    dict_index_t*   index,
    const ulint*    offsets,
    ReadView*   view)
{
    ut_ad(dict_index_is_clust(index));
    ut_ad(page_rec_is_user_rec(rec));
    ut_ad(rec_offs_validate(rec, index, offsets));

        // 对于InnoDB处于只读模式或者表为临时表的情况永远都是可见的。
    if (srv_read_only_mode || dict_table_is_temporary(index->table)) {
        ut_ad(view == 0 || dict_table_is_temporary(index->table));
        return(true);
    }

    // 获取行记录上的事务id。
    trx_id_t    trx_id = row_get_rec_trx_id(rec, index, offsets);

    // 判断是否可见。
    return(view->changes_visible(trx_id, index->table->name));
}

下面再来看看ReadView::changes_visible方法的实现源码:

bool changes_visible(
    trx_id_t        id,
    const table_name_t& name) const
    MY_ATTRIBUTE((warn_unused_result))
{
    ut_ad(id > 0);

    // 如果行记录上的id<m_up_limit_id或者等于m_creator_trx_id则可见。
    if (id < m_up_limit_id || id == m_creator_trx_id) {

        return(true);
    }

    check_trx_id_sanity(id, name);

    // 如果行记录上的id>=m_low_limit_id,则不可见。
    if (id >= m_low_limit_id) {

        return(false);

    } else if (m_ids.empty()) {

        return(true);
    }

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

    // 二分判断是否在m_ids中,如果存在则不可见。
    return(!std::binary_search(p, p + m_ids.size(), id));
}

理一下这里判断的依据

  • 记录的事务id为m_creator_trx_id即当前事务的修改,一定可见。
  • 记录的事务id<m_up_limit_id,说明Read View在初始化的时候,修改此记录的事务已经提交了,因此可见。
  • 记录的事务id>=m_low_limit_id,说明Read View在初始化的时候,修改改记录的事务还没开启(准确说是还没被分配到事务id),因此不可见。

如果这里不满足的话,会走到row_sel_build_prev_vers_for_mysql->row_vers_build_for_consistent_read的调用,根据回滚段中的信息不断构建前一个版本信息直至当前事务可见。

3.2 走二级索引的情况

bool
lock_sec_rec_cons_read_sees(
    const rec_t*        rec,
    const dict_index_t* index,
    const ReadView* view)
{
    ut_ad(page_rec_is_user_rec(rec));

    if (recv_recovery_is_on()) {
        return(false);
    } else if (dict_table_is_temporary(index->table)) {
        return(true);
    }
    // 取索引页上的PAGE_MAX_TRX_ID字段。
    trx_id_t    max_trx_id = page_get_max_trx_id(page_align(rec));

    ut_ad(max_trx_id > 0);

    return(view->sees(max_trx_id));
}

下面是ReadView:sees的实现,可以看到其实就是判断是否PAGE_MAX_TRX_ID小于ReadView初始化时的最小事务id,也就是判断修改页上记录的最大事务id是否在快照生成的时候已经提交了,简单粗暴的很。

bool sees(trx_id_t id) const
{
    return(id < m_up_limit_id);
}

因此这里lock_sec_rec_cons_read_sees方法如果返回true,那么是一定可见的,返回false的话未必不可见,但下一步就需要利用聚簇索引来获取可见版本的数据了。

在这之前InnoDB会先利用ICP(Index Push Down)根据索引信息来判断搜索条件是否满足,如果不满足那也没必要再去聚簇索引中取了;若ICP判断出符合条件,则会走到row_sel_get_clust_rec_for_mysql方法中去聚簇索引中取可见版本数据。

4. 总结

本文通过InnoDB源码,介绍了Read View的基本数据结构和概念以及InnoDB中是如何通过创建的Read View来判断可见性。实际上Read View就是一个活跃事务的快照,并且RC和RR隔离级别都复用了同样结构的Read View来判断可见性,不同的是Read View的生命周期根据相应的隔离级别而有所不同。

5. 参考

MySQL官方手册

数据库内核月报

原文地址:https://www.cnblogs.com/micrari/p/8144339.html

时间: 2024-11-02 05:08:39

初探InnoDB MVCC源码实现的相关文章

undrop for innodb c_parser 源码分析

一,主函数功能: 1,分析命令行参数,保存在全局变量中; 2,打开文件,加载表定义sql,调用分析函数开始处理; 3,打印导入数据的sql语句; 二,文件处理函数,void process_ibfile(int fn): 1循环读每一页面,调用分析页面函数去去处理,process_ibpage(page); 其中会检测如果只恢复删除记录时,删除记录要有效 三,处理页面的函数,process_ibpage(page_t *page) : 1,打印转储文件中当前页面的信息,包括页面ID,格式,记录表

菜鸟系列Fabric源码学习 — MVCC验证

Fabric 1.4 源码分析 MVCC验证 读本节文档之前建议先查看[Fabric 1.4 源码分析 committer记账节点]章节. 1. MVCC简介 Multi-Version Concurrency Control 多版本并发控制,MVCC 是一种并发控制的方法,一般在数据库管理系统中,实现对数据库的并发访问.在数据库系统中,锁机制可以控制并发操作,但是其系统开销较大,而MVCC可以在大多数情况下代替行级锁,使用MVCC,能降低其系统开销.MVCC是通过保存数据在某个时间点的快照来实

innoDB源码阅读笔记--缓冲池

最开始学Oracle的时候,有个概念叫SGA和PGA,是非常重要的概念,其实就是内存中的缓冲池.InnoDB的设计类似于Oracle,也会在内存中开辟一片缓冲池.众所周知,CPU的速度和磁盘的IO速度相差可以用鸿沟来形容,因此聪明的前辈们使用了内存这个ROM来弥补这道鸿沟,那么数据库的设计者们也继承了这个优良的设计理念,在内存中开辟了一片区域,存放缓冲数据,提高数据库效率. 可以将磁盘的缓冲区理解成一个简单的模型--由数据块组成的一片区域,数据块(block/page)默认大小是16KB.那么现

Python源码剖析笔记3-Python执行原理初探

Python源码剖析笔记3-Python执行原理初探 本文简书地址:http://www.jianshu.com/p/03af86845c95 之前写了几篇源码剖析笔记,然而慢慢觉得没有从一个宏观的角度理解python执行原理的话,从底向上分析未免太容易让人疑惑,不如先从宏观上对python执行原理有了一个基本了解,再慢慢探究细节,这样也许会好很多.这也是最近这么久没有更新了笔记了,一直在看源码剖析书籍和源码,希望能够从一个宏观层面理清python执行原理.人说读书从薄读厚,再从厚读薄方是理解了

InnoDB源码分析--缓冲池(三)

转载请附原文链接:http://www.cnblogs.com/wingsless/p/5582063.html 昨天写到了InnoDB缓冲池的预读:<InnoDB源码分析--缓冲池(二)>,最后因为着急看欧洲杯,没有把线性预读写完,今天接着写. 线性预读是由这个函数实现的:buf_read_ahead_linear,和随机预读一样,首先是要确定区域边界,这个边界内被访问过的page如果达到一个阈值(BUF_READ_AHEAD_LINEAR_THRESHOLD),就会触发预读操作.边界的算法

minidlna源码初探(二)—— SSDP设备发现的大致流程

前言: 之前有专文介绍了minidlna中的UPNP功能,内中介绍其中包含的SSDP(简单发现协议),SOAP(简单对象访问协议)等几个协议(http://blog.csdn.net/sakaue/article/details/19070735).本文将根据minidlna的程序流程,概述SSDP的流程,为下一部分ACE实现做铺垫. 设备发现的大致流程: 首先,根据UPNP的规范: 在设备加入网络,UPnP发现协议允许设备向控制点广告它的服务.它使用向一个标准地址和端口多址传送发现消息来实现.

InnoDB源码分析--缓冲池(二)

转载请附原文链接:http://www.cnblogs.com/wingsless/p/5578727.html 上一篇中我简单的分析了一下InnoDB缓冲池LRU算法的相关源码,其实说不上是分析,应该是自己的笔记,不过我还是发扬大言不惭的精神写成分析好了.在此之后,我继续阅读了Buf0rea.c文件,因为这里写的就是如何将block读取到内存中的函数. 这个文件里很显眼的有这样一个函数:buf_read_page,这是一个高层的函数,它的作用就是:reads a page asynchrono

MySQL系列:innodb源码分析之redo log恢复

在上一篇<innodb源码分析之重做日志结构>中我们知道redo log的基本结构和日志写入步骤,那么redo log是怎么进行数据恢复的呢?在什么时候进行redo log的日志推演呢?redo log的推演只有在数据库异常或者关闭后,数据库重新启动时会进行日志推演,将数据库状态恢复到关闭前的状态.那么这个过程是怎么进行的呢?以下我们逐步来解析. 1.recv_sys_t结构 innodb在MySQL启动的时候,会对重做日志文件进行日志重做,重做日志是通过一个recv_sys_t的结构来进行数

MySQL系列:innodb源码分析之page结构解析

在表空间结构分析当中,我们知道innodb的最小物理存储分配单位是page页,在MySQL-3.23版本的源码中,页只有两种页,一种是index page,一种是undo page.其类型值定义在fil0fil.h当中. FIL_PAGE_INDEX                         数据索引页,在表空间的inode page和xdes page都是属于这类. FIL_PAGE_UNDO_LOG                事务回滚日志页. 在这里我们主要分析的是 index p