云联信息：云盘 IOPS 不够，数据库会莫名其妙变慢

数据库没改代码、数据量也没暴涨，查询却越来越慢。查 CPU 和内存都正常，慢查询日志里的语句执行计划也没变。这种情况，多半是云盘的 IOPS 到顶了。

先确认云盘类型

普通云盘、SSD 云盘、增强型 SSD，性能差好几倍。很多实例默认配的是普通云盘，跑数据库勉强能用，数据一多就捉襟见肘。

IOPS 有上限也有突发

部分云盘有突发额度，短时间能跑高，持续高负载就掉下来。数据库这种持续随机读写的场景，突发额度很容易用完。

看监控里的磁盘指标

IOPS、吞吐量、等待时间三个指标，哪个到顶就是瓶颈。只看 CPU 使用率，永远发现不了磁盘的问题。

小容量盘性能也受限

IOPS 常与容量挂钩，一百G的盘和五百G的盘，性能上限不同。为省钱买小盘，性能也跟着缩水。

数据库和日志分开盘

日志写入是顺序的，数据库是随机的，放一块盘会互相抢 IO。分开之后，两者都更稳定。

临时盘不能存数据

本地临时盘性能最好，但实例重启就清空。只能放缓存和临时文件，放数据库等于给自己埋雷。

读写分离缓解压力

读多的业务，加只读实例分担。但根本问题还是磁盘性能，长期方案仍是升级云盘或拆分数据。

扩容后要重新观察

换了更好的盘，慢查询应该明显减少。如果没变化，说明瓶颈不在磁盘，回去看锁等待和索引。

数据库参数也要匹配

换了高性能云盘，数据库的并发写入、刷盘策略也要跟着调。参数不调，磁盘性能发挥不出来，钱花了效果有限。

监控要看等待时间

IOPS 没到顶但等待时间很长，说明队列堆积。这个指标比 IOPS 更能反映实际体验，也更容易被忽略。

扩容前先做基线

记录当前的 IOPS、吞吐、延迟，扩容后对比。没有基线，改完也不知道到底改善了多少，无法判断投入是否值得。

成本要算隐性部分

镜像仓库、构建机、监控采集，都是额外开销。只算服务器费用，容易得出容器更便宜的结论，实际不一定。

团队共识要提前建

容器会改变开发和运维的分工。没有共识就推进，最后变成开发不管部署、运维不懂镜像，问题互相推。

数据库变慢先看磁盘，比翻代码快得多。云联信息【资深云服务专家微信：cloud7591】的做法是把磁盘 IOPS 和等待时间加进核心监控，出现拐点时第一时间知道，而不是等用户投诉。

如果预算只够改一处，优先升级数据库所在那块盘的性能，收益通常比加内存或加CPU更直接。

换盘之后记得重新跑一次慢查询统计，把改善的数据记录下来，下次扩容时就有了判断依据。