记一次mysql cpu占用达到300%的生产事故

前几天离职，正在找工作面试呢，突然接到前老板的电话，说是系统挂掉了，公司上下一筹莫展。然后说晚上回去帮他看看，回去的时候本来以为问题应该解决了，但是他们还没解决，已经一整天了，客服电话都打爆了，用户现在很生气。需要马上解决。

       我知道后也是立即开始查看情况，从他们那儿得知，mysql不行了，cpu占用太大 300+% 所有的接口都没法访问,重启啥的都没有用，我也是比较奇怪，以前不是好好的吗，怎么突然就这样了,类似下面这种情况。

       我首先怀疑是代码的问题，先回滚项目版本，发现并没有什么卵用， 后面我怀疑是数据库有什么问题，我把数据库迁移到另外一台服务器，试了试，还是没什么卵用，最后查看druid的监控，发现有一些sql执行的非常慢，而且并发非常高，这是一个日志表，每天有大量日志插入和删除。所以我怀疑是这里出了问题，我首先关闭这个接口。重启项目发现mysql正常了。检查了这张表，发现非常大，有1000w+的数据，又有索引限制，所以可能原因是这张表的插入和删除过慢导致的。后面删掉一些没有用的日志，临时解决了这个问题，老板也很大方，直接给我包了个大红包。

       总结，项目挂掉时，首先要以先保障项目运行为第一步，所以代码要做好备份，有问题立刻回滚。其他要有一些服务器和数据库做测试和备用使用，监控也非常重要。查看监控可以看到很多问题的根源。  mysql单表数据超过几百万条的时候就要进入警戒线了。及时想办法解决。另外，平时也要去druid后台监控看看，如果发现了有执行特别慢的sql,就要及时处理。否则如果问题积压，到后面就不好处理了。以前用druid监控还发现了一个定时任务的sql查询要5小时才能执行完。就是之前没有优化的结果，后面花了大力气才解决。

      目前给他们提供了几种解决方案。1.分表，按时间划分日志表。2读写分离。3,使用redis.