最近经历了一次MyISAM重启的血泪教训，小小的故障历经3个小时才全部解决完毕，特此铭记一下，以后坚决防止在同一个地方跌倒两次。
事情的过程：
某日早7点接到几条主库报警，给值班组打电话后得到的消息是有一台交换机重启了。so，第一反应，这种情况不用处理过会就好了。（后来才知道，这是条虚假消息，没有上去验证是一个巨大的错误，代价惨重。）
等到了8点，依然收到报警，并且有越来越多的趋势。赶紧实际登陆服务器验证，发现服务器被重启了，上面的MySQL实例被意外shutdown。这时候从工作群中知道好几台同机房的服务器都出现相同情况，第一反应，一个机架掉电了。于是就赶紧重启吧，重启好了就奖从库都change到最新的pos上，检查一下主库正常，从库也同步正常。
再过一会，到了9点，迎来了第一个小高峰，主库瞬间扛不住了，负载飙高到1000+。上服务器check一下服务发现满篇的show processlist都是check table和repair table。业务也开始大幅的接到投诉，没辙，赶紧切换主库吧。但是，由于已经启动主库，中间涉及较多的数据一致性问题，切换脚本用不上，只能手工操作。
最终10点才把所有收到影响的端口都change完毕，并进行了交叉检查。但是，依然有众多的从库出现数据不一致问题，需要重做，这将持续一天。
是什么导致一次小小的重启引发长达3个小时的故障呢？
经验总结：
1、经验主义要不得。第一时间应该上到服务器上确认主库情况，不能存在侥幸心理。
2、报警的监控应该分级控制，对于主库宕机，需要频繁多次的报警，杜绝感觉是误报的心理作用。
3、对于MyISAM表，意外关机重启之后，一般都会面临check table的操作，如果表大，那么check一个小时以上是家常便饭。
所以，对于MyISAM表，如果意外重启，千万不要重启主库，直接进行主库切换操作。这是恢复故障最快的方法，没有之一。
这里多说一下，为什么重启主库之后一切正常，主要原因为没有用到crash的表，而早高峰到来的时候，所有crash的表被用户，触发了check table操作，导致同时repair表，最终引发了雪崩。
4、沟通，工程师最爱干的事情就是钻到问题中去解决问题。缺乏一个统一的指挥体系，导致故障处理时间拖长，如果第一时间进行主库切换而不进行其他尝试，故障时间可以大大节省。
ps:由于一般都是innodb引擎的，对于myisam表的谨慎度不够，由此引发两个问题，其一就是尽快完成引擎升级，都替换成innodb，其二就是在实际操作之前需要确认一下使用的引擎情况。