本人在做測試服務的過程中，開發了一個功能，就是從兩個庫的兩張表從查出來一個賬號的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聯合索引。不知道誰修改了表索引，真是一口老血噴薄而出。
解決方案：恢復表索引。