mysql中的Innodb_buffer_pool_reads和Innodb_buffer_pool_read

mysql中的Innodb_buffer_pool_reads和Innodb_buffer_pool_read_requests

Innodb_buffer_pool_reads和Innodb_buffer_pool_read_requests是什么？

mysql服务器维护了很多状态变量（status variables),这些变量提供了其相关操作的信息。

我们可以通过SHOW [GLOBAL | SESSION] STATUS 查看这些变量以及变量值。这些变量有很多，Innodb_buffer_pool_reads和Innodb_buffer_pool_read_requests是其中的两个，我们可以通过SHOW [GLOBAL | SESSION] STATUS like '%innodb_buffer_pool_%'命令来查看它们。

SHOW [GLOBAL | SESSION] STATUS like '%innodb_buffer_pool_%'

Innodb_buffer_pool_reads和Innodb_buffer_pool_read_requests的含义？

Innodb_buffer_pool_reads

Innodb_buffer_pool_reads

The number of logical reads that InnoDB could not satisfy from the buffer pool, and had to read directly from disk.

InnoDB是MySQL数据库使用的一种存储引擎。它将数据存储在内存中的缓冲池中，称为InnoDB缓冲池。

当从数据库请求数据时，首先搜索InnoDB缓冲池。如果数据未在缓冲池中找到，则必须将其从磁盘读入缓冲池。这也就是官网上说的Cound not satisfy from the buffer pool，缓冲池中无法中找到满足条件的数据，而必须从磁盘中读入缓冲池，这个操作称为Innodb_buffer_pool_reads（InnoDB缓冲池读取）。

Innodb_buffer_pool_reads读衡量了需要从磁盘读取到缓冲池的次数。

通常情况下，我们希望Innodb_buffer_pool_reads的值越小越好，因为它表示从磁盘中读取数据页到缓冲池中的次数越少，缓冲池的命中率越高，查询性能和系统响应时间也会更好。

如果Innodb_buffer_pool_reads的值较大，则可能表示缓冲池的大小不足或者热数据没有被缓存到缓冲池中，需要增加缓冲池的大小或者优化MySQL的查询语句，以提高缓存命中率和减少磁盘I/O的次数。

Innodb_buffer_pool_read_requests

Innodb_buffer_pool_read_requests

The number of logical read requests.

当从数据库请求数据时，首先搜索Innodb缓冲池，如果数据已经在缓冲池中存在，则可以从磁盘读取，此操作称为Innodb_buffer_pool_read_requestsInnoDB（缓冲池读取请求）。

InnoDB缓冲池读请求指标衡量了InnoDB能够直接从缓冲池中读取满足数据请求的次数，而无需从磁盘中读取数据。

与Innodb_buffer_pool_reads不同的是，Innodb_buffer_pool_reads衡量了需要从磁盘读取数据到缓冲池的次数，而Innodb_buffer_pool_read_requests衡量了数据已经在缓冲池中而无需从磁盘读取数据。

Innodb_buffer_pool_reads涉及到 IOPS 资源的消耗，Innodb_buffer_pool_read_requests涉及到 CPU 资源的消耗。

Innodb_buffer_pool_read_requests与CPU的关系

有时候我们可以会看到一些CPU 100%的场景，并且cpu的上涨曲线与Innodb_buffer_pool_read_requests的上涨曲线是一致的。如下图所示：

而这种现象是什么原因导致的呢？

大量的逻辑读对CPU的压力比较大是因为 InnoDB 缓冲池的工作机制需要大量的 CPU 计算来完成。

当 InnoDB 需要读取一个数据页时，会先在缓冲池中查找该页，如果该页已经在缓冲池中，则可以直接从缓冲池中读取；如果该页不在缓冲池中，则需要从磁盘中读取，然后将该页加入缓冲池中。

在这个过程中，需要进行大量的 CPU 计算，例如：

计算数据页的哈希值，用于在缓冲池中查找该页；
计算数据页的校验和，用于检查数据页是否被破坏；
执行 LRU 算法，用于决定哪些数据页应该被淘汰；
管理缓冲池的互斥锁，避免多个线程同时修改缓冲池等问题。

而这种情况一般是服务中存在一些低效SQL，导致查询执行成本高，为了获得结果集需要访问大量的数据（平均逻辑读很高），这种情况可能是小表的全表扫描，或者索引的效率不高。这种情况下，mysql的qps可能并不会很高。

关于衡量SQL的执行成本，可通过其需要扫描的表数据行数和结果集数据行数的比率来衡量。该比率越小说明查询语句效率越高。

在处理MYSQL CPU性能问题时，我们可重点关注下Innodb_buffer_pool_read_requests指标。

总结

Innodb_buffer_pool_reads衡量了需要从磁盘读取数据到缓冲池的次数； Innodb_buffer_pool_read_requests衡量了数据已经在缓冲池中而无需从磁盘读取数据；
Innodb_buffer_pool_read_requests涉及到 CPU 资源的消耗，我们在处理CPU性能问题时可重点关注该指标；

参考：

https://dev.mysql.com/doc/refman/5.7/en/server-status-variables.html https://developer.aliyun.com/article/165980