春天到了大地都复苏了，沉寂了很久的cpu也开始慢慢复苏了，所谓前人埋坑后人填坑，伴随着阿里云监控报警，线上CPU使用率暴增，于是就开始了排查之路。

由于服务的cpu暴增到达一定程度，导致服务假死，接口调用全部返回502不可用，链接超时导致服务器方面无法给予正常的反应。

通过查看阿里云数据库RDS，慢sql日志进行分析，发现数据库的CPU使用率在某一时间到达了96%，这不完犊子了。

导出监控平台分析的慢sql，看到这个sql平均的执行时间，真的是再次刷新了我的认知，平均执行法时间2分多钟，这怕是执行的黄花菜都要凉了。

首先根据阿里云分析的慢sql进行再次分析，sql肯定是有问题的，而导致服务不可用的原因还需要看微服务的负载配置，于是我去查看了该服务Nacos的配置。这里我们看到该服务Ribbon超时时间为15妙，就意味着接口如果执行超过这个时间接口就无法继续执行，从而出现服务假死不可用的现象。

服务接口调用长时间没有反应，ribbon负载均衡会触发熔断机制，对服务进行保护，让服务不可调用。

通过慢sql对应到问题接口，对接口逻辑进行梳理，排查接口涉及到的sql。 通过对业务逻辑分析，发现这个接口对慢sql执行了两次，一次是正常分页查询数据，第二次是没有加分页参数，那么将全表查询，对查询的结果根据字段进行过滤，过滤出count条数。

其次是发现前端对这个接口进行两次调用，咱也不知道为什么，但是在请求上看来，访问该页面同一接口确实进行两次调用，本来接口就很慢了，这简直就是一个暴击。

因为动态sql比较长，我只挑选我认为sql不是很合适的地方

2. sql中出现大量字段in的查询

In是走索引的查询，但是当in括号里面的条件比较多的情况下，就是传入的参数这个list列表长度比较大的情况下，是不走索引的，会进行全表扫描，in最终走不走索引其实是跟后面的数据有关系的。

关联表出现了很多重复数据，因为不了解之前业务的逻辑，不太清楚为什么出现很多重复数据，这也是表中数据量很大的原因，从而导致影响查询效率。

既然现在问题找到了，就可以进行优化了，我说下我优化的思路，主要是从下往上进行优化。

3. 业务代码方面，限制了时间筛选的区间，从原来的不限时间勾选范围，跟业务进行沟通后，调整为只允许选择一周的时间范围进行查询，前后端都进行限制。

由此可见优化后的执行效率还是比较高的，线上服务也没有在报警了，但是还有其他服务在报警…. 还有磁盘使用率到达90%…. Wtf真的是优化之路途漫漫啊。

此次对于接口的优化点还不是很深，主要点是对代码、sql、业务进行优化，还未涉及到分表、加入缓存热点数据进行预热、修改负载均衡超时时间等… 其实偶尔的填坑也是一种学习的方式，不说了继续填坑了，哦！不对优化代码了～