前言
春天到了大地都复苏了，寂静了很久的cpu也开始缓缓复苏了，所谓前人埋坑前人填坑，随同着阿里云监控报警，线上CPU使用率暴增，于是就开始了排查之路。
呈现问题景象
因为服务的cpu暴增达到肯定水平，导致服务假死，接口调用全副返回502不可用，链接超时导致服务器方面无奈给予失常的反馈。
通过查看阿里云数据库RDS，慢sql日志进行剖析，发现数据库的CPU使用率在某一时间达到了96%，这不完犊子了。
导出监控平台剖析的慢sql，看到这个sql均匀的执行工夫，真的是再次刷新了我的认知，均匀执行法工夫2分多钟，这怕是执行的黄花菜都要凉了。
问题排查
首先依据阿里云剖析的慢sql进行再次剖析，sql必定是有问题的，而导致服务不可用的起因还须要看微服务的负载配置，于是我去查看了该服务Nacos的配置。这里咱们看到该服务Ribbon超时工夫为15妙，就意味着接口如果执行超过这个工夫接口就无奈继续执行，从而呈现服务假死不可用的景象。
服务接口调用长时间没有反馈，ribbon负载平衡会触发熔断机制，对服务进行爱护，让服务不可调用。
波及接口
通过慢sql对应到问题接口，对接口逻辑进行梳理，排查接口波及到的sql。
通过对业务逻辑剖析，发现这个接口对慢sql执行了两次，一次是失常分页查问数据，第二次是没有加分页参数，那么将全表查问，对查问的后果依据字段进行过滤，过滤出count条数。
其次是发现前端对这个接口进行两次调用，咱也不晓得为什么，然而在申请上看来，拜访该页面同一接口的确进行两次调用，原本接口就很慢了，这几乎就是一个暴击。
慢sql剖析
因为动静sql比拟长，我只筛选我认为sql不是很适合的中央
查问列中用select嵌套查问
- sql中呈现大量字段in的查问
In是走索引的查问，然而当in括号外面的条件比拟多的状况下，就是传入的参数这个list列表长度比拟大的状况下，是不走索引的，会进行全表扫描，in最终走不走索引其实是跟前面的数据有关系的。
表中数据量
主表大略在25w多数据，关联表比拟大在170w数据。
主表索引加了很多，未必就是一件坏事，索引的设置齐全依照搜寻条件来设置也未必对，波及到关联表肯定要增加索引。
关联表呈现了很多反复数据，因为不理解之前业务的逻辑，不太分明为什么呈现很多反复数据，这也是表中数据量很大的起因，从而导致影响查问效率。
接口优化
既然当初问题找到了，就能够进行优化了，我说下我优化的思路，次要是从下往上进行优化。
慢sql优化，次要是针对嵌套查问改为left join 左外联查问，缩小了in查问，查问进去的数据在代码中进行筛选，缩小了一些不必要的索引。
通过conut()统计须要的条数，在所有count外面，count()是效率最高的了，有趣味的敌人能够去理解下。
- 业务代码方面，限度了工夫筛选的区间，从原来的不限工夫勾选范畴，跟业务进行沟通后，调整为只容许抉择一周的工夫范畴进行查问，前后端都进行限度。
优化后果比照
由此可见优化后的执行效率还是比拟高的，线上服务也没有在报警了，然而还有其余服务在报警…. 还有磁盘使用率达到90%…. Wtf真的是优化之道路漫漫啊。
总结
此次对于接口的优化点还不是很深，次要点是对代码、sql、业务进行优化，还未波及到分表、退出缓存热点数据进行预热、批改负载平衡超时工夫等…
其实偶然的填坑也是一种学习的形式，不说了持续填坑了，哦！不对优化代码了～