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