什么时候该升级内存规格

前言

在平时的工作中，会碰到用户想升级规格的case，有一些其实是没有必要的，这些通过优化设计或者改写SQL语句，或者加加索引可以达到不升级的效果，而有一些确实是需要升级规格的，比如今天讲的case。

追根溯源

查看表结构和索引

通过CloudDBA 的SQL统计功能，发现SQL比较简单，也有索引，所以排除是这两方面设计的问题。

查看实例性能数据

innodb_buffer_pool命中率还不到99%，命中率不高的，而iowait>=2略微高，所以推测是命中率不高，导致数据在内存里换进换出导致。

系统层面io对列里面已经有少量的堆积；

查看内存内容

通过查看内存里面的数据和索引的大小，可以看到：

+--------+--------+---------+---------+---------+------------+---------+
| engine | TABLES | rows    | DATA    | idx     | total_size | idxfrac |
+--------+--------+---------+---------+---------+------------+---------+
| InnoDB |  11274 | 899.60M | 247.21G | 187.56G | 434.77G    |    0.76 |
+--------+--------+---------+---------+---------+------------+---------+

数据和索引已经将近440G，而BP却还是1G，更加可以印证上面的推测(数据在内存里面被频繁的换进换出)。 再来验证下：

过十多分钟再看，BP里面的内容已经不一样了：

查看实例是如何用的

通过上一步我们可以发现，整个实例的空间是400G+，qps，tps都很低，逻辑读不算高，为什么BP命中率会这么低呢？ 通过

mysql>show global variables like "%buffer_pool%";

看到innodb_buffer_pool才1G，所有问题都已经明朗，那么如何解这个问题呢？

解决问题

我们再进一步看这个实例下面其实是有几十个库的，解决这个问题有两种方法：

1. 直接升级整个实例规格
2. 拆库

这么大的磁盘空间，又这么低的tps，所以我推荐第2种方法，拆分后其实也相当于变相地达到了升级实例规格的目的。把大实例拆成小实例后，再来看下对比：

结言

这个case是真正申请的内存规格小了些，所以这个是需要升级内存规格的。