Innodb_buffer_pool_read_requests探究之路
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，尝试着从根本上去理解它。
