小丸子踩“坑”升级——与mysql相关的接口性能问题

背景介绍

最近小丸子好不容易学习掌握了php实现服务接口的技能，服务上线后，功能没有问题，可是，某些查询信息类接口性能表现实在太差，弄得小丸子是焦头烂额。当然这也是小丸子初学者考虑不周所导致的。那小丸子最近这段时间在与mysql 相关的接口性能问题上，都踩过哪些“坑”呢？~~

查询接口性能差，主要现象分为以下两类：

表中数据量大时，接口性能差；

环境不同，接口性能表现不同；

表中数据量大时，接口性能差

我们可以利用explain显示mysql如何使用索引来处理select语句以及连接表。可以帮助选择更好的索引和写出更优化的查询语句。用法如下：

explain的信息有10列，分别为id、select_type、table、type、possible_keys、key、key_len、ref、rows、Extra，具体expain中信息含义及如何调优，相关资料已十分完备，因此不多做赘述。在此主要用到了两个相关的信息：key（实际使用的索引）、rows（找到所需的记录所需要读取的行数）。

（1）索引问题；

根据key我们就可以知道在查询过程中是否使用了索引，索引不必多说，可以大大提高MySQL的检索速度，因此查询是否使用了索引，是一个基本的性能关注点。

（2）返回数据量过多；

事例描述：小丸子在某一次排查查询接口时，日志中发现某条sql执行时间为0.2388s，分析后发现，在创建索引的前提下，查询结果数据量太大，导致语句查询慢。小丸子只好去请教“高手”，“高手”给予了两点建议：

是否需要返回查询条件的全量数据。先确认此查询语句是否有逻辑上的问题？通过增加其它where条件，返回的数据子集是否满足需求？

是否可以分批取全量数据。譬如是否可以利用分页形式，分批取数据，减少查询返回的数据；

后续处理：小丸子发现原来业务逻辑需求，并不需要查询条件下的全量数据，而是可能增加where条件，取其子集即可。通过调整，性能问题当然得到了解决。

环境不同，接口性能表现不同

由于不同mysql连接方式不同，导致单条查询语句不同环境消耗时长不同，当sql查询语句过多时，接口总响应时间随查询语句个数成线性增长。

事例描述：小丸子在某接口上线后发现，在代码及数据一致的情况下，此接口性能在测试环境与线上环境下差异很大。分析发现，原来测试环境连接的为本机数据库，基本可以忽略网络消耗，但线上环境连接却为另外ip的数据库，因此会有部分的网络消耗，从而导致在代码及数据一致的前提下，线上的性能较测试环境差很多。并且，当查询语句过多时，接口总响应时间随查询语句个数成线性增长。

后续处理：环境差异，这是一个较为隐秘的“问题”。对于此接口的处理方法为：在将单条sql性能调优的前提下，利用代码逻辑，处理查询返回数据，减少查询sql总数。已知此“问题”后，在后续的开发过程中，也要将此作为编写代码时的一个考虑因素。

经过这段时间的磨练，小丸子如果再遇到性能问题，目前采取的排查步骤如下：

测试环境与线上环境表结构是否一致（主要为索引）；

单条sql语句查询时间，寻找性能差的sql语句；

利用explain判断sql性能，是否可通过增加索引、减少查询时必须检查的行数等优化性能；

修改代码逻辑，利用where或分页或减少查询次数，来减少接口所有sql 的总查询时间；

这是小丸子目前遇到一些与mysql相关的接口性能问题，如果有童鞋有遇到过其它的，欢迎交流~~

路漫漫其修远兮，吾将上下而求索~~

Qtest是360旗下的专业测试团队！

是WEB平台部测试技术平台化、效率化的先锋力量！