前言

最近项目对外的提供的接口响应速度超级慢，查了查日志，有些接口请求处理时间竟然达到了惊人的1分多钟，这对于一个接口服务来说，应该是令人发指了吧。

迫于领（心）导（里）的（过）压（意）力（不去），硬（心）着（急）头（如）皮（焚）来找找原因。

查找问题

首先核对了日志表，抽取了一天的数据，早中晚几个节点分别抽查了一些接口请求记录，验证了下从收到请求数据到响应回去的时间，在请求低峰期的响应时间还凑合能看，但是在高峰期（早上9点至下午16点）响应时间从4秒至2分钟不等。

因为我的接口还要调用第三方的接口，所以也排查了下是否是第三方响应慢的原因，但结果却是出奇（意料之中）的一致，都是在毫秒之间就响应回来，而在第三方接口响应回来后，给接口调用方返回结果之前最是耗时。

查了查代码，在这之间做的操作只有记录接口来往日志这一个操作，于是乎，第一反应就是“是不是数据量太大了”，查了下日志表数据量，已经达到了惊人的170W（经波总提醒，这点数据量只是毛毛雨，完全谈不上大数据量，不过对于没见过大世面的我来说，当时确实吓着了）。

解决问题

找到了问题所在，接下来就是解决问题，第一反应就是把数据清出去（建个备份表，把今天以前的数据全扔进去），结果清出去后再观察日志发现，接口响应时间确实加快了，以为就这样结束了。

后来咨询了波总关于大数据量的处理办法，完全被波总藐视（只是自己觉得，可敬的波总很尽心的在帮我）了，“毛毛雨”的数量就是证据。

原因分析

经过波总的一番教导，我深刻的认识到，原来出错的原因是日志索引有问题，也确实，经过证实，日志表确实没有建索引，其他表都建的有，只有日志表建的匆忙而忘记建索引。

未建索引前，查询一条数据需要1.3秒左右，而建了索引后只需要0.03秒。

在波总的强烈建议下，将项目中用到的所有附带WHERE条件的SQL语句都通过explain命令做了验证，验证所写的SQL是否能匹配上索引，并根据验证结果对各表进行了索引优化。

具体explain命令的解释请参考另一篇文章：https://www.cnblogs.com/gomysql/p/3720123.html

最后的最后

这件事儿在大牛面前不是个事儿，可对于我这种没见过世面的程序猿来说算是大事儿了，也足足的给我上了一课，希望大家认识到索引的重要性，现次感谢波总。