前言
在平時的工作中，會碰到使用者想更新規格的case，有一些其實是沒有必要的，這些通過優化設計或者改寫SQL語句，或者加加索引可以達到不更新的效果，而有一些确實是需要更新規格的，比如今天講的case。
追根溯源
檢視表結構和索引
檢視執行個體性能資料
innodb_buffer_pool命中率還不到99%，命中率不高的，而iowait>=2略微高，是以推測是命中率不高，導緻資料在記憶體裡換進換出導緻。
系統層面io對列裡面已經有少量的堆積；
檢視記憶體内容
通過檢視記憶體裡面的資料和索引的大小，可以看到：
資料和索引已經将近440G，而BP卻還是1G，更加可以印證上面的推測(資料在記憶體裡面被頻繁的換進換出)。 再來驗證下：
過十多分鐘再看，BP裡面的内容已經不一樣了：
檢視執行個體是如何用的
通過上一步我們可以發現，整個執行個體的空間是400G+，qps，tps都很低，邏輯讀不算高，為什麼BP命中率會這麼低呢？ 通過
看到innodb_buffer_pool才1G，所有問題都已經明朗，那麼如何解這個問題呢？
解決問題
我們再進一步看這個執行個體下面其實是有幾十個庫的，解決這個問題有兩種方法：
直接更新整個執行個體規格
拆庫
這麼大的磁盤空間，又這麼低的tps，是以我推薦第2種方法，拆分後其實也相當于變相地達到了更新執行個體規格的目的。把大執行個體拆成小執行個體後，再來看下對比：
結言