一个MySQL索引引发的血案

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

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

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

我先把程序在本机上和内网的服务器上都跑了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联合索引。不知道谁修改了表索引，真是一口老血喷薄而出。

解决方案：恢复表索引。