这些年碰到的MySql最多解决耗时的严重问题

      09年后，我将服务器从windows迁移到linux，也从熟悉的sqlserver 迁移到了mysql数据库。

这10年里每过3年出现一次严重问题。但总是忘记这类问题该如何处理，导致都要折腾个3，4个小时，才是完。

     之前遇到的具体经过已经无法记得了。就最近一次来说，也是一年前了。

晚上10点，云服务器报警，系统cpu 占用100%，应用服务无法访问。当时我的第一感觉，是不是被攻击了。登录云管理，看到流量还是正常。按理不会是被攻击。再次想到是不是病毒引起，但这些年也没处理过linux上的病毒，也只能说是没遇到过，想着如果是这问题，那就只能重装系统了。

于是停掉应用服务，cpu是降下来了。于是再打开，自测没有问题。以为搞定了。不到10分钟，又短信报警。这下的认真对待了。于是停掉服务。在跟踪查看的时候，发现mysql占用内存比较高，于是停止mysql。这个停止过程耗费10分钟。在启动mysql时，确发现无法启动，找到mysql的日志路径。提示无空间。于是我删除一下服务日志释放了点空间，但还是无法启动。此时也折腾了半个小时，服务停止了这么久运营人员开始电话了，于是病急乱投医，重启了服务器。又是20分钟过去，但还是没有将数据库启动起来，一直在报无空间。

于是，使用 du -h --max-depth=1 / 命令，去定位哪个地方占用了大空间。经过10分钟努力，终于找到目录，是一服务写的日志，估计是存在bug，好像是今天下午上线的，也先不管责任的事情了，于是删除这个占用了上百g的日志文件，然后停止掉这个服务，mysql终于启动了。启动后，发现很多表无法打开，需要修复。也没去找修复命令，直接使用mysql客户端，每个表进行打开，打开后会自动修复。

想想这些年出现的耗时事故，今日再次总结一下解决方法：

1. 云服务器监控的时候，将硬盘空间占用率也添加到报警里面，比较大部分的事故，会从无空间开始，然后延伸到数据库奔溃，如果运气好，清理空间数据库还是能正常运行，也有可能需要重做数据库。
2. 新上线的服务，最好多测试测试，不要着急上线，否则它可能就是个雷，特别是不是自己写的，出了问题自己都蒙圈。