记一次生产环境慢SQL导致数据库服务器CPU打满，APP应用无响应故障

记一次生产环境慢SQL导致数据库服务器CPU打满，APP应用无响应故障

问题描述：突然接到通知前端APP应用特定功能连接超时，无响应，通过Grafan监控查看发现生产服务的内存几乎都达到上限，通过APM查询发现请求大量堆积，接口响应严重超时，mysql连接数达到了近400，找到APM监控到的慢sql,进行分析，发现一个主题下，竟然有70多万个回复（开始以为是被攻击了），正是由于对此条数据的多此查询导致mysql响应缓慢，先处理掉此条数据，处理后mysql恢复正常，应用服务器恢复正常，APP已能正常访问，全都恢复后，开始排查数据来源，最后发现问题出在一个之前数据增量同步kafka的接口上，之前的数据已经同步完成，不知为何接口又开启了（怀疑是那个谁发布时手误，给打开了），导致kafka里70多万条记录都写到了一个主题下，自此，问题全部解决，反思中间出现的问题，中间经历了，生产环境重启，相关接口分析，mysql相关分析，第一时间拿到慢sql后，没有从合理性的角度去分析，最先做的是准备通过执行计划去分析，准备对相关sql进行调优，开发人员的局限性，害死人呀。 1.突然接到通知前端APP应用特定功能连接超时，无响应，通过Grafan监控查看发现生产服务的内存几乎都达到上限:

2.通过APM查询发现请求大量堆积，接口响应严重超时，mysql连接数达到了近400:

3.此时的mysql服务器CPU严重标高：

4.找到APM监控到的慢sql,进行分析，发现一个主题下，竟然有70多万个回复（开始以为是被攻击了），正是由于对此条数据的多此查询导致mysql响应缓慢，先处理掉此条数据，处理后mysql恢复正常，应用服务器恢复正常，APP已能正常访问。

5.全都恢复后，开始排查数据来源，最后发现问题出在一个之前数据增量同步kafka的接口上，之前的数据已经同步完成，不知为何接口又开启了（怀疑是那个谁发布时手误，给打开了），导致kafka里70多万条记录都写到了一个主题下，自此，问题全部解决，反思中间出现的问题，中间经历了，生产环境重启，相关接口分析，mysql相关分析，第一时间拿到慢sql后，没有从合理性的角度去分析，最先做的是准备通过执行计划去分析，准备对相关sql进行调优，开发人员的局限性，害死人呀。