本人在做测试服务的过程中,开发了一个功能,就是从两个库的两张表从查出来一个账号的login_id和user_id,功能非常简单,就是执行sql语句,处理返回结果,再返回。
之前执行一直没有问题,但是昨天测试同事跟我说查询功能特别慢。打了日志,竟然耗时30000+s,简直突破天际。下面我说一下自己排查思路和最后的解决办法。
首先我想到了网络问题,因为我本机是连着VPN连到的公司内网。
我先把程序在本机上和内网的服务器上都跑了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联合索引。不知道谁修改了表索引,真是一口老血喷薄而出。
解决方案:恢复表索引。