最近换了一家新公司，面试领导告诉我说接口响应很慢，然分配任务给我去优化接口，然后就有了下面的一些遭遇。
在不了解业务的情况下，需要先找测试定位接口，找到接口之后，开始品味代码了。我个人优化的方式是在每一次的逻辑处理处，打印出处理时间的长度，类似下图：
这样很容易知道这段代码处理所需要的时间，那么也能知道整个接口中，那些地方处理时间过长。通过日志输入定位到范围之后，开始查看代码内部的处理逻辑。
这是一个很简单的根据uid查询出所有信息，大家看我画出来的地方，用到的参数只有2个，但是sql的返回参数却是全量返回了。如果用的是自己接下来这里很多刚入门的同学都会犯这个错误。这里我还是解释一下，返回全量的影响：1、数据库用的是mysql，懂得人都知道，大部分数据查询是会回表的，但是如果全部命中是可以减少回标操作的 ，从而减短查询消耗的时间 ；2、数据量返回少了，传输的速度就快了；所以这里我修改了部分参数返回，速度从2秒缩短到200毫秒。可想而知一个简单的操作提高的速度是多大，接下来继续看代码。
看到一个for循环，那么我心里开始想到什么了，我继续往下看，意料之中，for循环嵌套了sql查询，很显然这位同学对自己没一点要求，一般对自己有点要求的肯定是不会这样写的，这样写代码能快鬼都不信
测速的时候这里花了大概19秒，循环才几十次就这样的耗时了，那要是几百条循环这系统没法跑了，所以大家一定要注意，数据能一次性查出来就一次性查出来，不能就利用其他组件去实现提前查好数据，反正办法总会比问题多，对自己提高一点要求。相同的问题就不多说了。
使用reids的同学一定要注意。因为接下来这位同学利用上了reids缓存，但是技术不到位，导致了缓存穿透。大量的数据去数据库查询了，数据库也没有，这里的问题是设计不合理，前端没拦截导致不规则数据条件进行了查询，我暂时的解决办法是用了正则去拦截，暂时先用着，优化也不是一蹴而就的，慢慢来，所以大家使用redis的时候一定要记得定义规则，一切按照规则进行操作，不然会出现很多问题。
以上简单的描述了一下遇到的问题，如果大家遇到类似的问题，可以参考。
