線上問題之慢Sql一定是Sql慢嗎

問題解答

答案是不。就我現在的經驗來分析，引起慢Sql的原因有兩個，第一個，真的慢，第二個，資源被別人佔用，鎖不釋放，導致我們的sql一直阻塞，變成慢sql。那麼，為什麼資源會被一直佔用麼，那就說明你的事務時間太長，可能是其他執行的sql慢或者其他的IO操作阻塞(比如Http呼叫)。

問題覆盤

今天臨近下班在釘釘收到兩個線上預警，而且都是@我的。

第一個是呼叫推送Api超時了，我看了下，沒怎麼在意，覺得是偶發情況吧。
第二個是慢sql，並且這個是update語句，重複相同的13個相同sql超時，但是就語句來看 應該是命中索引的，本身執行肯定快，成為慢sql肯定是資源被佔用了。但是看了程式碼我也沒發現什麼特殊的地方（這個模組的推送我這期重構了改成非同步了）。就認為是其他地方資源佔用，導致這邊被超時了。

但是後面我經驗豐富的TL經過程式碼分析一下問題後，真相浮出水面。

這個問題Sql是在一個訊息的消費者程式碼中，偽邏輯如下

//事務開始
修改訂單資訊（佔用資源，其他執行緒阻塞）
修改對應訂單車輛為起運
推送(超時了)
其他系統索引同步
//事務結束

一個訂單有13輛車，所以有13個起運訊息發動過來，並且是併發的，當第一條訊息消費的時候，推送方法超時了，10秒的timeout才返回，那麼其他消費者就會阻塞在第一句修改的sql呼叫上。直到第一條消費結束，過了10多秒，其他的消費者才從阻塞中依次恢復。

上面看視沒有關聯的兩個告警聯絡到了一起，不過我沒看出來的問題，我覺得還是因為我這個版本已經重構掉了。。不是現場的程式碼。

以後對於線上告警，我要好好重視，都是學習的機會。

問題總結

不要在事務內執行除了資料庫操作以外的會引起阻塞的呼叫，比如推送，發短息，同步索引這些操作，都進行非同步解耦。

還有一個公司的監控系統真的是相當重要。

下面是我公眾號，大家可以關注下。