mysql表多了后很卡_大量MySQL表导致服务变慢的问题

背景

有一个业务需要分 1000 个库，每一个库中都有 80 个表，总共就是 80000 * 2 个文件。文件使用率还挺高，大概是 60000 * 2。

这个业务采用的高可用架构是 MMM，由于集群机器在硬件检查时发现有问题，必须要换掉。于是想了一个比较简单、影响面较小的方法去解决，就是找了另外两台机器迁移过去。同时，要求这四台机器属于同一个网段，VIP(虚拟 IP 地址)在机器之间可以漂移，这样业务就不需要修改 IP 地址即可迁移，相当于两次主从切换过程。

切换方案如图 16.1 所示。

从图 16.1 中可以看到，切换过程很简单，如下三步。

先将原来的写节点(db1)与一个新的节点(db3)切换成一套集群，也就是把在 db2 上面的 VIP(读流量)切换到 db3 上面，此时 db1 与 db3 组成一套新集群。

接着将 db1 和 db3 的角色互换，让 db3 成为写节点，db1 成为读节点。

最后，再将 db1 读节点上面的 VIP(读流量)切换到 db4 上面，此时新的集群就是 db3 和 db4，db3 为写节点，已经切换完成。这样的变更是晚上做的。做好之后，观察了一段时间，发现没有什么问题(因为压力小)，所以觉得事情完成了，睡吧。 第二天上班之后，业务反映说迁移之后，数据库比原来慢了 10 倍(10 倍啊！感觉不可思议)。询问了一番，说没有任何变更，只是做了迁移之后就成这样了。同时经过观察，只有写库的读操作变慢了，而读库的读是不慢的。最后，业务已经受不了了，要求切换回去。还好，db1 还正在从 db3 复制，做了一个回退操作，把写挂在 db1 上面，把读挂在 db3 上面。神奇的是，问题解决了！好吧，那就先这样，走出去的路不能回头，总是要迁出去的，所以先在新旧两台机器上面挂着，查明原因后再切换回去(这样少做一步)。

以上是背景。

问题分析

环境对比

db1 写入时，db1 写不慢，读不慢，db3 也不慢。

db3 是新的硬件，db1 是老的、有问题的硬件。

db3 切换成写之后，在慢查询文件中明显看到很多慢查询(使用相同的语句查询，原来是 50ms，现在是 500ms)，和监控是一致的。

db1 和 db3 配置文件有差别，如图 16.2 所示(左边是 db3 的，右边是 db1 的)。