一个MySQL索引引发的血案

本人在做测试服务的过程中,开发了一个功能,就是从两个库的两张表从查出来一个账号的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联合索引。不知道谁修改了表索引,真是一口老血喷薄而出。

扫描二维码关注公众号,回复: 4343796 查看本文章

解决方案:恢复表索引。

至此,邮件已发,等着开会。

欢迎有兴趣的一起交流:群号:340964272

猜你喜欢

转载自blog.csdn.net/Fhaohaizi/article/details/84616886
今日推荐