记一条慢sql引发的血案

    事情经过是这样的，一天下午，一位同事在后台查询一个用户的业务记录，结果半天页面没有响应，于是一边抱怨着一边狂点查询，还是没查出来，最后终于放弃了；然后没一会儿，系统开始不停报警，也开始有用户反馈说登录不了，页面打不开等等；赶快排查哪里出了问题，看日志发现执行数据相关操作全是error，正好有一个系统半个小时前发布过，于是紧急回滚，问题也在同步排查，系统回滚完发现情况并没有好转，这时另一个同事说数据库好像挂了，一看果然cpu一直在100%左右，于是重启数据库，然后一切恢复了正常。

    事后发现事故发生时一条慢sql被频繁执行，最终整个数据库挂起，而同一个数据源上分布着用户中台和多个业务中台，所有数据都拒绝访问，结果就是全站都不能正常服务了。再看那一条慢sql很熟悉，因为之前就有注意到它，只是当时数据量还没这么大，它也没这么慢，而且当时的想法是慢点就慢点儿呗，反正是后台的功能，另一方面解决方案（业务表有原来的逻辑分区改为物理的分库分表）已经开始实施，没想到正好这个时候该暴露的问题还是暴露出来了，这是一个血的教训。

    事故暴露出两个问题，一个直接的是慢sql的问题，以前不是很重视，以为只是慢，结果发现如果慢还是能接受的，那么它也会毫不留情面告诉你我不光慢，我还能高挂整个库，这是一个很详实的教训，慢sql一定要重视，如果短期内不能解决，也要有临时解决方案和最终解决方案，不能拖；另一个相对隐藏的问题，那就是把多个核心数据库放到同一个数据源下，我们一直在想办法提高系统的可用性，于是划分了业务线，抽出,了中台，结果数据源挂了，所有系统的可用性变成了0，这像是一个笑话，但根源上还是在整体是设计上缺乏对数据库设计的重视，事后对核心数据库做了迁移，同时增加只读库的使用。