一场mysql查询引起的“卡顿” 作者: 灯小笼 时间: 2018-09-03 分类: 架构 评论 一般我们说优化mysql，总是会将着眼点放在mysql的慢查询的优化上，或者字段的数据类型，mysql的分库/分表，读写分离，异或事务这些看上去高大上的东东上。但是，对于一些更加基础或者更加常识的地方，往往会加以忽视。就比如，本文将要提到的：mysql的查询本身的优化。 这次接到的优化任务出现的背景是： 我们有一个内部电话呼叫的系统，在下午使用客服相对较多的时候，在很随机的情况下，会出现突然的卡顿，这种现象维持的时间很短，检查的时候，往往发现cpu、内存、负载、网络，都很正常，查询错误日志也看不到异常。 系统用的是阿里云，2C4G，看负载的曲线也维持得很小很平稳，内存消耗也没有达到瓶颈。中间一度怀疑过对缓存的使用有问题，因为有很多临时数据都是通过cache在传输和保存的，调用频率也很高。于是，负责此项目的同学也做过很多方面的优化，想过很多招数。比如： 1、临时数据的保存从全量改为增量，大大降低了数据传输的量。 2、将数据库改成长连接，减少连接使用量。 原来我们使用的数据库是由阿里云提供的，后来降配了，长连接经常出现连接数不够的时候，又改为普通连接了。最后，我们又把mysql改成了自建，连接数2000，还是够用的。不过，即使使用长连接的时候，依然会出现卡顿，索性，就一直维持着使用普通连接了。 - 阅读剩余部分 -
