专栏首页腾讯云数据库专家服务MySQL 案例:innodb_buffer_pool_read_requests 解读
原创

MySQL 案例:innodb_buffer_pool_read_requests 解读

背景

近期时不时会遇到用户结合 MySQL 指标异常的情况来反馈数据库的问题,可能也有很多公司开始重视 DBA 这个职位了吧(这是好事)。也借机研究一下这些指标的细节,本次解读的指标是innodb_buffer_pool_read_requests

问题描述

接到用户的咨询,反馈innodb_buffer_pool_read_requests和 CPU 指标同时出现了突增,希望帮忙定位一下问题的原因,并给出一些建议。

原因分析

既然带上了具体的指标,那么分析起来就会方便很多,由于 requests 和 reads 的指标一般是一起用的,所以翻文档的时候一起看一下官方文档的介绍:

Innodb_buffer_pool_read_requests The number of logical read requests. 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.

官方文档的介绍还是比较简单直白的,检查完用户的监控数据之后,发现 requests 比较高,reads 很少,说明用户的查询并没有涉及到磁盘 IO,但是存在大量逻辑读,因此一般情况下是查询的效率不太高,可能是中小表全表扫描,或者是索引的效率不高,导致查询的时候仍旧扫描了较多的数据。

这里一般的建议是开启 SQL 审计或者调低慢查询的时间阈值,然后再去找对应的语句。

指标解读

虽说问题可以解释清楚,但是文档里面的细节很少,尤其是 requests 的指标只是提了一下逻辑读请求的数量,那么这个 requests 的维度是 SQL 级别的,每个 SQL 一个 request,还是每行数据一个 request?

开源的好处就是遇到不懂的地方可以爬源代码了(MySQL 5.7.31),requests 的指标是 global status 中的,那么 MySQL 一般有这个指标的具体示意以及内部结构体的参数定义,搜一下这个指标后,找到出处:

./storage/innobase/srv/srv0mon.cc
代码:
......
        /* 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;
......

可以看到源代码里面对这个参数的解释也是非常简略,不过能看到这个参数的值是 n_page_get 决定的,直观的看起来,比较像是 page 的获取数,那么看一下这个参数除了一些获取统计信息的方法以外,还在哪些地方用到了:

buf_page_get_zip:访问已压缩的 page,比如压缩过的 blob 数据
buf_page_get_gen:通用的 page 访问函数
buf_page_optimistic_get:特殊的访问方式,非通用型
buf_page_get_known_nowait:获取一个已存在的 page,比如说从 AHI 的记录中直接找到具体的 page
buf_page_try_get_func:尝试通过 tablespace id 和 page number 获取 page,如果没找到,则返回 NULL,而不是从磁盘读取

首先可以看出来这个指标就是指代的 page 数量,稍微看了一下通用的 page 获取方法,可以看到一个调用链:

row_search_mvcc -> sel_set_rtr_rec_lock -> buf_page_get_gen,在获取 row record 的时候,会调用这个函数,那么说明:如果多个行用到了同一个 page,那么这个 requests 的指标也会计算多次

PS:可能会有一些优化策略来减少单个 pages 反复读取的问题,不过不在本文探索的范围之内。

那么最初提出的疑问,至此就可以有个明确地回答了:这个 requests 的维度是 SQL 级别的,每个 SQL 一个 request,还是每行数据一个 request?

答曰:维度是数据库的 page,如果多行数据在同一个 page 里面,那么多次访问同一个 page 的时候也会记录多次

总结一下

innodb_buffer_pool_read_requests 这个指标由于记录的是 page 数,在直观的数值上其实是不太好单独用来判断读压力的,毕竟一行数据可能有多个 page,少量的行数可能就会导致这个指标飙升;而重复访问同样的少量 page 也会让这个指标飙升,但是这些 page 可能全部缓存在内存中,实际上不一定会影响查询效率。最好是能结合其他的指标一起来做判断。

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • Innodb_buffer_pool_read_requests探究之路

    Innodb_buffer_pool_read_requests,可以用来计算innodb命中率。但是这个值具体代表什么呢?

    老叶茶馆
  • MySQL中强大的mysqladmin

    如果对MySQL的性能测试工具,比如sysbench做压力测试就可以看到我们关注的性能指标QPS,TPS,压测过程中的性能变化一目了然。 而在平时的工作...

    jeanron100
  • Prometheus + Granafa 构建高大上的MySQL监控平台

    对于MySQL的监控平台,相信大家实现起来有很多了:基于天兔的监控,还有基于zabbix相关的二次开发。相信很多同行都应该已经开始玩起来了。我这边的选型是Pro...

    Bug开发工程师
  • MySQL 5.7 统计表记录数执行效率对比分析

    墨墨导读:MySQL在统计表记录数时,指定使用主键查询反而慢,在执行效率上进行对比分析。

    数据和云
  • MySQL数据库性能优化之一

    文章来自:博客 数据库属于 IO密集型的应用程序,其主要职责就是数据的管理及存储工作。而我们知道,从内存中读取一个数据库的时间是微秒级别,而从一块普通硬盘上读取...

    企鹅号小编
  • MySQL8.0内存相关参数介绍

    MySQL理论上使用的内存 = 全局共享内存 + max_connections×线程独享内存。

    MySQL技术
  • MYSQL PMM 搭建容易,细节难

    现在什么都要短平快,意思就是又要好,又要快,又要不出问题,嗯, 如果要监控MYSQL 来说,想要一个这样的东西 PMM monitor and mannagem...

    AustinDatabases
  • Mysql上线后优化项

    mysql> show variables like 'max_connections';

    子润先生
  • Mysql可调优的参数分享

    当MySql的连接数据达到max_connections时,新来的请求将会被存在堆栈中,以等待某一连接释放资源,该堆栈的数量即back_log。

    杨漆
  • MySQL大表优化技术,你都会了吗?

    除非单表数据未来会一直不断上涨,否则不要一开始就考虑拆分,拆分会带来逻辑、部署、运维的各种复杂度,一般以整型值为主的表在千万级以下,字符串为主的表在五百万以下是...

    Bug开发工程师
  • mysql常用配置注意项与sql优化

    肖哥哥
  • 老司机也该掌握的MySQL优化指南

    当MySQL单表记录数过大时,增删改查性能都会急剧下降,所以我们本文会提供一些优化参考,大家可以参考以下步骤来优化:

    Spark学习技巧
  • Python实现MySQL DBA小工具

      我们知道MySQL所有的运行状态统计信息都能从“show global status”语句的结果集中查看,该结果集保存的是从MySQL启动到当前时间之间各状...

    py3study
  • 性能优化-MySQL性能优化参数

    对配置参数的说明: 配置参数的格式如下:(shell > mysqladmin -uroot -ppassword variables extended-st...

    cwl_java
  • MySQL 大表优化方案

    除非单表数据未来会一直不断上涨,否则不要一开始就考虑拆分,拆分会带来逻辑、部署、运维的各种复杂度,一般以整型值为主的表在 千万级以下,字符串为主的表在 五百万以...

    纯洁的微笑
  • MySQL 大表优化方案,收藏了细看!

    当 MySQL 单表记录数过大时,增删改查性能都会急剧下降,可以参考以下步骤来优化。 单表优化 除非单表数据未来会一直不断上涨,否则不要一开始就考虑拆分,拆分...

    数据和云
  • MySQL 大表优化方案

    除非单表数据未来会一直不断上涨,否则不要一开始就考虑拆分,拆分会带来逻辑、部署、运维的各种复杂度,一般以整型值为主的表在千万级以下,字符串为主的表在五百万以下是...

    Bug开发工程师
  • MySQL 大表优化方案

    除非单表数据未来会一直不断上涨,否则不要一开始就考虑拆分,拆分会带来逻辑、部署、运维的各种复杂度,一般以整型值为主的表在千万级以下,字符串为主的表在五百万以下是...

    九州暮云
  • 如何优雅地优化MySQL大表

    除非单表数据未来会一直不断上涨,否则不要一开始就考虑拆分,拆分会带来逻辑、部署、运维的各种复杂度,一般以整型值为主的表在千万级以下,字符串为主的表在五百万以下是...

    Bug开发工程师

扫码关注云+社区

领取腾讯云代金券