出现的问题就是，某一天，忽然服务卡的要死，明明访问量没多少，但是响应时间直线上升，直奔着20秒+去了。
排查问题的流程是，首先去看数据库log，因为用的阿里云的rds，控制台上可以直接看log日志，发现有好多慢查询。再看其他数据库的监控等，连接数什么的，都是没有异常的。
第二步，复制出来sql,直接执行这个sql，看这个sql执行的时间，确认是数据库慢，还是程序慢。发现数据库几百毫秒就响应了。
第三步又去检测程序响应，首先怀疑是不是slb转发或者nginx转发出现了问题，把其中一个节点放出来做测试，直接外网用ip加端口访问，发现这个节点的响应速度是10秒+，然后我又在这个服务器节点上，内网请求了一下，1秒就响应了，这离谱的差距，让我直接怀疑是不是请求转发的问题。
第四步，开始检测是不是slb的原因。但是百度说阿里云slb有问题的帖子，大部分说是http和https请求转发速度有区别，和我的情况不符。
第五步，出于对阿里服务的信任，我又开始核实自己的服务。忽然发现，我在本地连续请求几次后，响应速度从1秒往上递增，最后几次请求，拖到40秒都没有数据返回
第六步，基本确认和人家的slb没关系了 我又开始审查代码，会不会有什么地方内存泄漏啥的,但是看了看服务器的top df啥的，也没有内存飚升的情况，包括我开两个窗口，一个用curl请求一下接口，一个看服务器参数数据，发现服务慢的一直没返回数据，但是cpu啥的没有飙升情况，就基本排除是程序问题，那问题可能就在数据库了。
第七步，忽然想起那个慢sql了，又去执行这个sql,发现直接执行这个sql，每请求一次，响应时间也是直线上升，几次后，响应时间直接飚到快两秒了。（就只是一个宽表的查询而已，limit拿到10条数据，虽然没加索引，但是也不能离谱到两秒吧.....）
第八步，开始回忆，服务响应慢的这个问题出现，做了什么，忽然想到，这个宽表，有个字段，字符串，用来存一些规则说明的，然后字段不够了，存不下了，就增大了这个字段的长度........
好吧，已经定位到问题了，是一个超级低级的错误，改小这个字符串长度后，程序立马恢复了，绝了。
一个血淋淋的建议，不要动生产环境的任何东西，哪怕是你觉得没有任何影响的一个小改动。