总结一次系统宕机问题

@ 总结一次系统宕机问题（大神可以忽略，本篇文章给小白们指条明路）

问题简单描述:

2019年9月6号12点左右，在公司楼下吃饭，突然接到了公司运营的电话，反馈系统宕机，系统服务全部停止，别的不说上截图

首先进入日志发现后台的dubbo服务全部阻塞，线程全部占满，导致系统全面宕机（系统架构 SpringBoot+mbs+dubbo+redis）首先查看系统快照以及cpu占用率查看问题，发现全部服务阻塞。排查时间大约10分钟左右，突然灵机一动，想查看一下生产数据库，查看cpu以及占用内存，

突然吓傻了，cpu竟然以笔直的形式冲上了百分之100，所有的问题一刹那解开，初步排查问题：有一条或多条慢sql查询或者别的操作，将数据库cpu拉满，导致阻塞了除了用到redis之外的服务，数据库宕机是罪魁元首，导致所有关于数据库的操作全部等待响应，在控制台将所有sql进程kill掉，cpu直线下滑。。。jenkins重启双节点，服务重新运行。。。满身大汗。。。。

开始排查问题

将rds数据库上的慢sql全部导出，发现有一条sql运行了0.9秒左右，并且查询cpu以及该sql运行大致时间发现符合事故发生时间

突然纳闷了，为什么一条update没有连表，竟然执行时间竟然会达到0.9秒，我蒙了，身为3年程序猿，竟然会在这个sql翻车？？？，仔细排查发现正常的单表update只需要0.03~0.05秒左右。。。为什么这个update会执行如此之久。。。

排查后发现正常的update 是通过id 来进行的，但是我这条sql是通过用户的openId来修改用户的关注公众号状态，但是这个openId未建立索引。。竟然会运行0.9秒以上…果断增加数据库索引

运行时间直接下滑到0.06秒，唉。。。。心累，
只怪当初偷懒，没加索引，导致系统宕机，以及扣除百分之40绩效。。。哭了

问题总结

1.除非是通过id进行update ，否则大批量数据表中，要在合适的地方新增索引增加查询以及修改速度！！！

2.想明白为什么通过该字段进行update操作，可不可以 通过表主键id进行查询以及修改操作。。。

3.最重要一点，遇到事情不要慌，昨天中午差点吓尿了，公司ceo直接拍我肩膀说怎么样。。留我一个人在风中凌乱。。。。

感谢大家观看，小弟献丑了，以后我会多多分享项目经验以及踩坑经验。还有关于阿里云iot以及java问题可以私信评论，我可以和大家一起解决。再次感谢。。