前言
在平时的工作中,会碰到用户想升级规格的case,有一些其实是没有必要的,这些通过优化设计或者改写SQL语句,或者加加索引可以达到不升级的效果,而有一些确实是需要升级规格的,比如今天讲的case。
追根溯源
查看表结构和索引
通过CloudDBA 的SQL统计功能,发现SQL比较简单,也有索引,所以排除是这两方面设计的问题。
查看实例性能数据
innodb_buffer_pool命中率还不到99%,命中率不高的,而iowait>=2略微高,所以推测是命中率不高,导致数据在内存里换进换出导致。
系统层面io对列里面已经有少量的堆积;
查看内存内容
通过查看内存里面的数据和索引的大小,可以看到:
![45820b4c651db583cd915b4586b85d29ab7d2588](https://yqfile.alicdn.com/45820b4c651db583cd915b4586b85d29ab7d2588.png?x-oss-process=image/resize,w_1400/format,webp)
数据和索引已经将近440G,而BP却还是1G,更加可以印证上面的推测(数据在内存里面被频繁的换进换出)。 再来验证下:
过十多分钟再看,BP里面的内容已经不一样了:
查看实例是如何用的
通过上一步我们可以发现,整个实例的空间是400G+,qps,tps都很低,逻辑读不算高,为什么BP命中率会这么低呢? 通过
mysql>show global variables like "%buffer_pool%";
看到innodb_buffer_pool才1G,所有问题都已经明朗,那么如何解这个问题呢?
解决问题
我们再进一步看这个实例下面其实是有几十个库的,解决这个问题有两种方法:
- 直接升级整个实例规格
- 拆库
这么大的磁盘空间,又这么低的tps,所以我推荐第2种方法,拆分后其实也相当于变相地达到了升级实例规格的目的。把大实例拆成小实例后,再来看下对比:
结言
这个case是真正申请的内存规格小了些,所以这个是需要升级内存规格的。 一些小技巧,起到大作用,欢迎使用我们的经验沉淀下来的产品,您随叫随到的数据库专家CloudDBA。