mysql预留分区过多引发的血案

1.问题描述

今天我们在进行版本更新的时候，更新完成测试发现我们的mysql机器原来是可以扛住，但是今天更新完成之后发现mysql机器完全处理不过来连接的请求，系统一直以满负载状态运行，表现的状态是系统连接是满的，有很多连接超时的连接，连接池不够用。
mysql版本（5.7）

2.问题排查

1.排查过程中，我们发现有一个表是分区表，但是我们的查询条件因为是不带分区的，所以我们去慢查询里面排查发现很多0.2s左右的执行sql，我们正常都是0.1s之内的，经过排查发现其实我们查询数据只查到最近三天的分区（我们是按照天去分区的），但是我们的查询方式不会过滤到具体的分区，需要扫描所有分区，而且由于保留了原来历史分区，历史分区也有大量数据，所以会变慢，所以我们当时有两个解决方案，（1）改查询方式（2）删除有数据的历史分区，保留最近会查到的几天数据的分区。
2.从方案上来看，只能通过第二种去改，然后我们就去alter table drop partition删除历史分区，但是由于分区数量多，而且库里面也会有一些qps，执行drop partition的时候会有很多的mdl锁，由于当时还没有正式开服，所以我们重启了mysql服务，然后快速进行删除分区（这块儿解释一下为什么重启就会删除快一点，因为之前的话缓冲池会有很多的数据，再删除的时候需要先删除缓冲池等buffer相关的数据，再删除对应的分区表，我们重启之后buffer因为都刷盘了，所以再删除会快速很多）
3.删除完成之后，我们正式开服，发现系统的响应确实有提升但是处理连接还是很慢（因为qps很高），所以我们继续进行排查，结果发现各种方式都不行，最后没有办法我们删除了我们提前预留的一部分分区，预留了70多 删除了35个预留的分区
4.奇迹出现了，数据库处理连接性能立刻飙升，连接再也没有打满过。

3.问题结论

1.遇到这种问题，可以删除历史的数据分区，如果不行删除预留的分区。
（这块我自己想了一下，也自己去排查了，因为要打开所有分区表，所以分区表打开的消耗，因为qps很高，所以每个很小的累积起来会很多，还有就是需要去收集统计信息）
2.额外提一点（在5.7版本之前使用分区表的话，不要建立太多的分区，因为会导致打开文件数量超过open file limits参数）