线上sql执行慢,分享3个优化案例
前段时间,博主线上项目的几个后端接口执行耗时达到了三、四秒钟以上,查看接口代码,发现 sql 语句执行过慢,于是开始分析 sql 执行 这里把比较经典的优化案例分享给大家。[*]本文所讲述 MySql 8.0+
[*]代码演示地址:https://github.com/wayn111/newbee-mall-pro
[*]博主github地址:https://github.com/wayn111 欢迎大家关注,点个star
一、or 查询条件错误
线上有一个第三方账户扫码绑定手机号登录的接口,这个接口正常逻辑如下:
[*]使用 苹果、QQ、微信获取扫描客户端登录二维码,获取用户第三方账户唯一ID后。
[*]判断第三方账户ID是否存在用户表中,存在且已绑定手机号则直接返回用户 token 进行登录操作。
[*]不存在则提示用户进行绑定手机号操作。
[*]用户填写手机号及短信验证码后,进行第三方账户唯一ID与手机号的绑定,成功则返回用户 token 进行登录操作。
博主记得这个接口是在21年10月上线的,到现在经历了一年多,接口执行时间是越来越慢,初步分析是用户数量持续增长,用户表记录越来越多,导致 sql 查询执行效率越来越低导致。这里用 vc_member_bak 进行举例,表结构以及数据展示,其中 apple_id、weixn_id、qq_id 有建立索引:
vc_member_bak 表数据量在46万左右,开启日志分析后,发现是下面这条 sql 执行太慢导致:
SELECT * FROM vc_member
WHERE qq_id = 'xxx' OR app_id = 'xxx' OR weixin_id = 'xxx' ;执行结果:
需要1.3秒左右,这是在我本地模拟的数据,线上用户在百万级别,耗时已经达到2、3秒,于是博主开始上 explain,分析 sql 执行:
由于 explain 结果中 key 列为空,明显可知虽然 possible_keys 列有值,但是执行过程中,没有使用索引导致全表查询,从rows 列为46万可以看出已经基本接近于全表查询。
那么问题出在哪里?我们不是已经给 apple_id、weixn_id、qq_id 三个字段都添加索引了吗。
于是博主仔细查询 sql 语句发现里面有坑,查询的 where 条件上使用的三个条件字段是分别是 app_id、weixin_id、qq_id,而我们的索引字段是 apple_id、weixn_id、qq_id,很明显这是查询字段 apple_id 写成 app_id 了导致。app_id 没有加索引,所以在 or 条件查询下执行的就是全表扫描。
更改字段后执行结果:
Ok,这里发现了是查询字段写错了,那么修改查询字段正确后,查询0.18秒就正常了。
来源:https://www.cnblogs.com/wayn111/p/17234487.html
免责声明:由于采集信息均来自互联网,如果侵犯了您的权益,请联系我们【E-Mail:cb@itdo.tech】 我们会及时删除侵权内容,谢谢合作!
页:
[1]