Innodb_buffer_pool_read_requests探究之路

绝地灬酷狼 2023-02-20 07:41 79阅读 0赞

作者：魏新平，知数堂优秀校友。

Innodb\_buffer\_pool\_read\_requests，可以用来计算innodb命中率。但是这个值具体代表什么呢？

### 官方文档 ###

先从官方文档入手，文档就一句话。

> The number of logical read requests.

解释超级简单，代表的是逻辑读的次数。但是什么是逻辑读呢？百度了一圈，涉及到的文章也都是解释说是逻辑读或者直接说是read的次数，都是模糊不清的解释。也想过用google，但是自从vps欠费后，就没有然后了。那就只能从源代码里面找了。

### 官方源代码 ###

下载的源代码是官方的mysql-boost-5.7.29.tar.gz。

本人的c++水平接近于0。只限于大学的时候学过c语言，而且毕业到现在也快5年了，基本上也都还给老师了。工作的时候，一般使用的也都是python。还好语言都是互通的，搭配注释，还能看懂个大概。

用vscode打开源代码目录，全局搜索Innodb\_buffer\_pool\_read\_requests关键字。  
找到了如下代码

ulint innodb_buffer_pool_read_requests;    /*!< buf_pool->stat.n_page_gets */
    
    /******************************************************************//**
    Function to pass InnoDB status variables to MySQL */
    void
    srv_export_innodb_status(void)
    /*==========================*/
    {
       省略了部分代码
        export_vars.innodb_buffer_pool_read_requests = stat.n_page_gets;
       省略了部分代码
    }
    
    /* innodb_buffer_pool_read_requests, the number of logical
    read requests */
    case MONITOR_OVLD_BUF_POOL_READ_REQUESTS:
        buf_get_total_stat(&stat);
        value = stat.n_page_gets;
        break;

从上面涉及到的这些代码来看，Innodb\_buffer\_pool\_read\_requests背后的值应该就是n\_page\_gets。

接下来全局搜索n\_page\_gets，找到如下代码。

/** @brief The buffer pool statistics structure. */
    struct buf_pool_stat_t{
        ulint   n_page_gets;    /*!< number of page gets performed;
                    also successful searches through
                    the adaptive hash index are
                    counted as page gets; this field
                    is NOT protected by the buffer
                    pool mutex */
        省略部分代码
    };

这个是buffer pool的状态的结构体，类似于一种数据类型，可以用来保存各种buffer pool的状态值。这里的解释相对逻辑读来说就更加清晰一点。涉及到被操作的page的次数，包括adaptive hash indexde 的page。但是具体是什么，感觉还不是很清楚，接下来就要升级探索方法了。

### 调试mysql ###

搭建mysql的调试环境。对于一个没写过c++程序的人来说，调试这么大一个软件就相当于一个只玩过街机里面的飞机游戏的人尝试去开真飞机。艰辛的过程就不说了，大概花了两天吧，终于把调试环境搭建起来了（用的vscode在mac本地上调试）。

我比较关心的是对于select语句，这个值增加到底表示什么意思，那么调试语句就决定用select了。

##### 调试语句，表 #####

mysql> show create table t1;
    +-------+---------------------------------------------------------------------------------------+
    | Table | Create Table                                                                          |
    +-------+---------------------------------------------------------------------------------------+
    | t1    | CREATE TABLE `t1` (
      `a` int(11) DEFAULT NULL
    ) ENGINE=InnoDB DEFAULT CHARSET=latin1 |
    +-------+---------------------------------------------------------------------------------------+
    mysql> insert into t1() values(1),(2),(10),(11),(12);
    mysql> select * from t1;
    mysql> select * from t1 limit 2;
    mysql> select * from t1 limit 3;
    mysql> select * from t1 limit 4;
    mysql> select * from t1 where a=1;

t1表一个int字段，而且只有5条记录，一个page应该就能存放所有数据的。执行完上面的语句，逻辑读的值分别增加了6，2，3，4，6。从结果来看感觉和页似乎没啥关系，倒是查询的结果行数影响比较大。这个时候就要靠打断点来理解这个值的意思了。

调试的关键就是打断点。

因为测试的是select的语句，所以一开始直接在处理select语句的do\_select函数打断点，然后一步一步调试，探究这个值。调试了好几次，被淹没在了各种不认识的函数和语法当中爬不出来，这条路暂时是走不通了，就算走通，估计也要非常久了。

换一条路，直接全局搜索n\_page\_gets，在涉及到该值计算的函数都打上断点。

多次调试，发现下面两个函数会一直被调用。都是先调用buf\_page\_get\_gen,然后再多次调用buf\_page\_optimistic\_get。

/** This is the general function used to get access to a database page.
    省略部分代码
    @return pointer to the block or NULL */
    buf_block_t*
    buf_page_get_gen(const page_id_t&    page_id,省略部分代码)
    {
    省略部分代码
        buf_pool->stat.n_page_gets++;
    省略部分代码
    }
    
    This is the general function used to get optimistic access to a database page.
    省略部分代码
    buf_page_optimistic_get(buf_block_t*    block,  /*!< in: guessed buffer block */
    /*====================*/
    省略部分代码
    {
    省略部分代码
        buf_pool->stat.n_page_gets++;
    省略部分代码
    }

从注释来看这两个函数都是用来从数据页当中获取数据用的。而且这两个函数每次调用，n\_page\_gets都会加1。一个sql语句会多次调用上面的函数，而且调用次数和Innodb\_buffer\_pool\_read\_requests的增加值也一致。也就是说关键点就是上面两个函数了。

仔细观察这两个函数。buf\_page\_get\_gen有一个page\_id参数，然后返回一个block的指针。记得官方文档说过page也能叫做block，也就是说是通过page\_id来返回对应page的指针。buf\_page\_optimistic\_get有一个block的指针参数，这个block应该就是第一个函数返回的那个值。多次调试发现也确实如此，一个select语句多次调用这些函数，所用的都是同一个page（因为第一个page\_id和后来的block当中的page\_id都是一致的）。

但是为什么多次调用呢，而且似乎和行数有一定关系呢。这个时候就需要查看上游到底是什么再调用这两个函数了。通过call stack发现上层的关键函数是下面三个，调用关系是ha\_rnd\_next调用index\_read或者general\_fetch，然后再调用buf\_page\_get\_gen或者buf\_page\_optimistic\_get。

/**
      Read next row via random scan.
    
      @param buf  Buffer to read the row into
    
      @return Operation status
        @retval 0     Success
        @retval != 0  Error (error code returned)
    */
    
    int handler::ha_rnd_next(uchar *buf)
    {
    省略部分代码
    }
    
    /**********************************************************************//**
    Positions an index cursor to the index specified in the handle. Fetches the
    row if any.
    @return 0, HA_ERR_KEY_NOT_FOUND, or error number */
    
    int
    ha_innobase::index_read(
    /*====================*/
        uchar*      buf,        /*!< in/out: buffer for the returned
                        row */
        const uchar*    key_ptr,    /*!< in: key value; if this is NULL
                        we position the cursor at the
                        start or end of index; this can
                        also contain an InnoDB row id, in
                        which case key_len is the InnoDB
                        row id length; the key value can
                        also be a prefix of a full key value,
                        and the last column can be a prefix
                        of a full column */
        uint            key_len,/*!< in: key value length */
        enum ha_rkey_function find_flag)/*!< in: search flags from my_base.h */
    {
    省略部分代码
    }
    
    /***********************************************************************//**
    Reads the next or previous row from a cursor, which must have previously been
    positioned using index_read.
    @return 0, HA_ERR_END_OF_FILE, or error number */
    
    int
    ha_innobase::general_fetch(
    /*=======================*/
        uchar*  buf,        /*!< in/out: buffer for next row in MySQL
                    format */
        uint    direction,  /*!< in: ROW_SEL_NEXT or ROW_SEL_PREV */
        uint    match_mode) /*!< in: 0, ROW_SEL_EXACT, or
                    ROW_SEL_EXACT_PREFIX */
    {
    省略部分代码
    }

从上面三个函数的注释来看，innodb是一次从一个page里面获取一行处理，然后循环处理到最后一行。所以buf\_page\_get\_gen和buf\_page\_optimistic\_get函数的调用次数会和行数有关系。

这里面还有一个小疑问，为什么有limit时，增加的数值和Innodb\_buffer\_pool\_read\_requests增加的数值一样，但是没有时却都比扫描的行数多了一次呢？

我的猜想是使用limit的时候知道需要几行，所以innodb去获取的时候就知道需要调用几次。但是其他语句都是不知道要返回几行的，需要全表扫描，那么等到全部行获取完成后还需要再调用一次，判断还有没有剩的。最后一次general\_fetch函数的返回值也证实了我的猜测。最后一次调用的时候会返回error=137，也就是HA\_ERR\_END\_OF\_FILE错误,意味着扫到文件结尾了，不需要再扫了。

### 结论 ###

这次探究之路到这里也就结束了。**总结下来，Innodb\_buffer\_pool\_read\_requests的值代表的是page被处理的次数，就算是同一个page被处理多次也算是多次，而并非一次。**

万事开头难啊，经历了从没写过c++，到成功调试mysql软件，并且查出来自己想要探究的内容，成就感还是挺足的。接下来会更多的使用这种方式去学习mysql，尝试着从根本上去理解它。

全文完。

*  --------------------
    
     *  由叶老师主讲的知数堂「MySQL优化课」课程早已升级到MySQL 8.0版本了，现在上车刚刚好，扫码开启MySQL 8.0的修行之旅吧。  
        
        
         *  ![format_png][]
            
            --------------------
            
            另外，叶老师在腾讯课堂《**MySQL性能优化**》精编版第一期已完结，本课程讲解读几个MySQL性能优化的核心要素：**合理利用索引，降低锁影响，提高事务并发度**。
            
            下面是自动拼团的二维码直接享受组团价
            
            ![format_png 1][]

[format_png]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9tbWJpei5xcGljLmNuL21tYml6X2pwZy9udHM1Mm5IaGVUeEx5ajlRdWJEY0hQeUlwemgwaWNXSVpnTm96aFo3TmxDbW53MkU1ekpqUzZTTjE0TENaR0JvUW04WGliVHkzZDFtaWFqYWlhQVhTcTFTVVEvNjQw?x-oss-process=image/format,png
[format_png 1]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9tbWJpei5xcGljLmNuL21tYml6X3BuZy9udHM1Mm5IaGVUek5xdmliY3IwZmJDQkU3MXBoMzF5aWJ5TzNFOVJONnlLd0NYd1R6cVZmc1ZxM2RxUUFpYWRoUDlGSkVXOUluNlk0Mnl4ZTVUUWVuMm9BUS82NDA?x-oss-process=image/format,png