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

解決方案：恢復表索引。

至此，郵件已發，等著開會。

歡迎有興趣的一起交流：群號:340964272