---------------------------------------------------------------------------------------------
[版权申明：本文系作者原创，转载请注明出处]
文章出处：https://blog.csdn.net/sdksdk0/article/details/84565356
作者：朱培 ID：sdksdk0
--------------------------------------------------------------------------------------------
最近，测试妹子和前端向我反映说接口查询起来很慢，他们那边加载要挺久的，我满满自信的说不科学啊，我过去一看，好像的确是挺慢的，然后就决定来把这个问题解决一下。因为我的API服务以及部署在我们部门目前性能最好的服务器上面了，所以应该不是API服务器这个节点的问题，然后屁颠屁颠的查sql，分析发现有个词云表的查询非常慢，在打印sql的log的时候居然等了好几秒钟，语句如下，非常简单
select word,sum(num) as num from c_key_words where 1=1 GROUP BY word ORDER BY num desc limit 200
我觉得可以从这里入手，然后打开sql分析，一查发现，好家伙，费了我7s才出结果，可是我这个表目前只有2万条数据，不应该这么慢的，那来看看索引情况，
嗯，看到并没有索引，于是加个索引看看
通过explain分析，发现索引已经加上了，但是依然还需要7s才能出结果，我觉得这个不科学啊，然后转去mysql的服务器上面查询，看下连接数：
mysqladmin -uroot -p status;
然后发现是连接数过多导致的吧
Uptime: 71675 Threads: 1999 Questions: 7529317 Slow queries: 98517 Opens: 628 Flush tables: 1 Open tables: 606 Queries per second avg: 105.048
然后简单粗暴的重启了。。。。。。。
重启之后：
Uptime: 51 Threads: 19 Questions: 6783 Slow queries: 0 Opens: 414 Flush tables: 1 Open tables: 407 Queries per second avg: 133.000
问题解决了，但是为什么呢？是哪个程序导致的
因为目前用的不可能有这么多人，然后想到了肯定是哪里开启了连接但是并没有关闭，如何想到了我这边使用了websocket，莫不是使用完成后没有关闭连接。
然后去查websocket这台机器的日志，发现连接数果然过大，因为开发服务器这边连接的数量不可能超过20，所以很有异常
然后把前端抓过来，然后通过查找他代码，发现是网页刷新的时候没有关闭websocket,然后让他进行关闭。
我这边重启websocket服务，修改数据库my.cnf最大连接线程数，将其减小到和合理值，重启数据库服务，
搞定！
所以说遇到问题得综合分析，不一定一开始就去大动干戈的优化后端API代码，找到问题的原因很重要。