小丸子踩“坑”升级——与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平台部测试技术平台化、效率化的先锋力量!

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20180929B1F4GH00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。

扫码关注云+社区

领取腾讯云代金券

年度创作总结 领取年终奖励