FunTester 一个 MySQL 索引引发的问题

FunTester · 2020年03月31日 · 802 次阅读

本人在做测试服务的过程中,开发了一个功能,就是从两个库的两张表从查出来一个账号的 login_id 和 user_id,功能非常简单,就是执行 sql 语句,处理返回结果,再返回。

之前执行一直没有问题,但是昨天测试同事跟我说查询功能特别慢。打了日志,竟然耗时 30000+s,简直突破天际。下面我说一下自己排查思路和最后的解决办法。

首先我想到了网络问题,因为我本机是连着连到的公司内网。

我先把程序在本机上和内网的服务器上都跑了 N 次,结果差不太多。基本上把此条排除了,不是因为网络。

其次我想到了 MySQL 负载,于是去 MySQL 服务器看了一次各项指标,一切正常,基本把此条排除。

然后我把目标放在执行的 sql 语句上了。

下面是我执行的 MySQL 语句:
"SELECT l.login_name,u.user_id,l.login_id,u.sex FROM alpha_login.login_info l LEFT JOIN alpha_user.user_info u ON l.login_id = u.login_id WHERE l.login_id= " + id + " OR u.user_id = " + id + ";"

其中涉及到了一个联表的操作,两张表都不到 10 万条数据,开始怀疑数据库执行的问题。然后我用 Navicat 连接数据库,感觉不出来大的延迟,然后我去执行了一条 sql,果然很慢。看来不是 MySQL 服务的问题。

然后我取消连表查询,单独去查一条记录,测试结果非常快,从建立连接到返回结果,都是百毫秒级别的。

看来问题就应该出现在联表的问题,我仔细查找了两张表的结构,依然没有发现问题,我去使用两张表主键联立其他类似的表,返回结果两张表都 ok。这会儿有点奔溃了,跨库也不会这么慢啊,以前都还正常的,就是昨天测试同事跟我说查询功能特别慢。我再次使用两张表的 login_id 和 user_id 去联立其他表,惊奇发现 user_info 这张表奇慢无比。

重点来了,我去查表信息的时候,竟然发现除主键 user_id 之外竟然只有一条索引:user_id,瞬间想骂人了。因为之前 user_info 表的结构我查过,user_id 主键,user_id 和 login_id 联合索引。不知道谁修改了表索引,真是一口老血喷薄而出。

解决方案:恢复表索引。


  • 郑重声明:文章首发于公众号 “FunTester”,欢迎关注交流,禁止第三方(腾讯云除外)转载、发表。

技术类文章精选

无代码文章精选

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
暂无回复。
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册