FAQ系列:DB服务器产生大量物理读问题优化思路
Posted 茁壮的小草
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了FAQ系列:DB服务器产生大量物理读问题优化思路相关的知识,希望对你有一定的参考价值。
一 【现象】
1、7点到9点IO监控指标util特别高,如下:
2 、查看读写情况:读产生很高的物理IO,如下
【分析】:对比其他服务器,buffer pool都是80G,正常情况下热点数据都是从buffer pool中读取的,产生物理读基本很少,但是这组却产生了很多物理读,肯定是有问题的。
二 【找内鬼】
【基本思路】:既然产生了物理读,下一步我们很容易想到,是哪些表产生了物理io?更具体的就是这些表上哪些SQL会导致物理IO?
1、利用Performance_schema中file_summary_by_instance表统计IO情况。 2、写个脚本,分别统计在7点14到7点20、7点14分到8点14分这两个高峰期间,产生最多物理读的表是哪些。 3、找到表后,查看该表可疑的SQL,重点关注慢查询。
1、 通过统计performance_schema中file_summary_by_instance找到这两个高峰期间产生读物理IO最多的2个表
表已经定位到了,那么再深入一下,找到这些表上哪些SQL可能会导致大量物理读。通过我们开发的sql-trace平台或者通过performance_schema.events_statements_summary_by_digest进行统计。具体语句:
select DIGEST_TEXT,COUNT_STAR,FIRST_SEEN,LAST_SEEN from events_statements_summary_by_digest where DIGEST_TEXT like \'%`a1`%\';
2、 a1表上可疑的sql语句
SELECT Max(daydate)as daydate FROM a1 WHERE t_id =2572244 and bid>0;
3、 a2表上可疑的sql语句
SELECT Max(daydate)as daydate FROM a2 WHERE m_id =2572244 and bid>0;
为什么可疑?
可疑1、从时间段上看,以上sql执行时间和产生物理读比较吻合,都是7点到9点。如下:
可疑2、以上两个SQL都是慢查询。
可疑3、通过set profiling跟踪发现产生很多磁盘io,Block_ops_in=22176,Block_ops_out=664。
三 【验明正身】
找到负责的开发同学,发现是通过job跑的,为了确认是不是该SQL语句导致的问题,让开发同学把job延迟一个小时跑
第二天果然发现磁盘IO的高点也延迟了一个小时,到这里基本可以确定“内鬼”了。
以上是关于FAQ系列:DB服务器产生大量物理读问题优化思路的主要内容,如果未能解决你的问题,请参考以下文章