個人一個低級錯誤，致使數據庫崩潰半小時！！

1、反常的SQL語句

某週四午休時分，我正在工位上小憩，睡夢中彷彿看到了本身拿着李白在榮耀峽谷裏大殺四方的情景，就在我剛拿完五殺準備帶領隊友推對面水晶的時候，一句慌亂急促的「糟了」把我從睡夢中驚醒。

我眯開朦朧的雙眼，才發現剛纔的發聲來源於個人組長莊哥，看到他在緊張的點開日誌系統查看日誌，我預感到有什麼不妙的事情發生，仔細一問才知道，原來就在我眯眼的期間，線上數據庫服務器的CPU被打滿，同時觸發了生產數據庫只讀延遲的限定時間而且發出告警，並且告警的過程持續了半個小時。

這讓我倒吸了一口涼氣，由於咱們組作的系統不少都用的是同一個數據庫服務器，日用戶活躍量有好幾十萬，若是服務器崩潰了將會使全部的系統服務都不可用，因而咱們趕忙經過SQL日誌進行問題查找，最後排查出來是由於一張SQL的高量查詢沒有走索引致使，日誌列表顯示，這條sql語句的掃描行數達到了上百萬，基本就是全表掃描的狀況，並且半個小時的時間查詢了達上萬次，每條SQL查詢的耗時都在3000ms以上。

個人天啊，難怪服務器會CPU打滿，這麼一條耗時的SQL語句查詢量這麼大，數據庫的資源固然是直接就崩潰了，這是當時那條SQL的查詢狀況：

2、臨時處理

看了這條語句，我又倒吸一口涼氣，這不就是我寫的系統調用的SQL語句嗎？完了，這回逃不掉了，真是人在睡夢裏，鍋從天上來。

固然，由於是我本身寫的SQL，因此我一看就知道這條語句是有問題的。

根據個人代碼處理，這條sql的調用還少了個重要的參數user\_fruit\_id，這個參數沒有傳的話是不該該走這條sql查詢的，在個人設計裏，該參數是數據表裏一個聯合索引的最左側字段，若是該字段沒有傳值的話，那麼索引就不會生效了。

KEY \`idx\_userfruitid\_type\` (  
  \`user\_fruit\_id\`,  
  \`task\_type\`,  
  \`receive\_start\_time\`,  
  \`receive\_end\_time\`  
) USING BTREE

雖然定位到了SQL語句，可是線上的問題刻不容緩，總不可能找出bug改完再上線吧，因此，咱們只能作了一個臨時處理，就是在原來的表上多加了一個聯合索引，其實就是去掉了user\_fruit\_id 字段，讓這些高量的查詢都能走新的索引，就像下面這樣：

KEY \`idx\_task\_type\_receive\_start\_time\` (  
 \`task\_type\`,  
 \`receive\_start\_time\`,  
 \`receive\_end\_time\`,  
 \`created\_time\`  
) USING BTREE

加上索引後，sql的掃描行數就大幅度的下降了，重啓實例後就又能正常運行了。

3、最左匹配原則

那麼爲何最左側的字段沒傳索引就不生效了，這是由於MySQL的聯合索引是基於「最左匹配原則」匹配的。

咱們都知道，索引的底層是B+樹結構，聯合索引的結構也是B+樹，只不過鍵值數量不是一個，而是多個，構建一顆B+樹只能根據一個值來構建，所以數據庫依據聯合索引最左的字段來構建B+樹。

例如咱們用兩個字段（name，age）這個聯合索引來分析，

當咱們在where條件中查找name爲「張三」的全部記錄的時候，能夠快速定位到ID4，而且查出全部包含「張三」的記錄，而若是要查找「張三，10」這一條特定的數據，就能夠用 name = "張三" and age = 10 獲取。

由於聯合索引的鍵值對是兩個，因此只要前面的name肯定的狀況下就能夠進一步定位到具體的age記錄，可是若是你的查詢條件只有age的話，那麼索引就不會生效，由於沒有匹配最左邊的字段，後面全部的索引字段都不會生效，因此我以前寫的sql語句纔會由於少了最左邊的user\_fruit\_id字段而走了全表掃描的查詢方式。

正常來講，假設一個聯合索引設計成(a,b)這樣的結構的話，那麼用a and b做爲條件，或者a單獨做爲查詢條件都會走索引，這種狀況下咱們就不要再爲a字段單獨設計索引了。

但若是查詢條件裏面只有b的語句，是沒法使用(a,b)這個聯合索引的，這時候你不得不維護另一個索引，也就是說你須要同時維護(a,b)、(b) 這兩個索引。

4、找出Bug

雖然臨時作了處理，但問題並不算解決，很明顯是系統出現了bug纔會有走這樣的查詢條件。

由於是我本身寫的代碼，因此知道是哪條SQL後我就立刻定位到了代碼裏的具體方法，後來才發現是由於我對user\_fruit\_id字段的判空處理不生效所致。

由於該字段是從調用方傳過來的，因此我在方法參數裏對該字段作了非空限制的註解，也就是javax包下的@NotNull。

public class GardenUserTaskListReq implements Serializable {  
  
    private static final long serialVersionUID = -9161295541482297498L;  
  
    @ApiModelProperty(notes = "水果id")  
    @NotNull(message = "水果id不能爲空")  
    private Long userFruitId;  
    /\*\*如下省略\*/  
    .....................  
}

雖然加上該註解來作非空校驗，但我卻沒有在參數加上另外一個註解@Validated，該註解若是沒加上的話，那麼調用javax包下的校驗規則就都不生效，正確的寫法是在controller層方法的參數前面加上註解：

除此以外，由於user\_fruit\_id這個字段是另外一張表的主鍵，我在代碼裏也沒有對這張表是否存在這個id作查詢判斷，這樣一來，不管調用方傳什麼值過來都會直接觸發sql查詢，而且在不跑索引的狀況下直接走全表掃描。

不得不說，這真是個低級錯誤，說真的，我對這個緣由真是感到嘀笑皆非，再怎麼說也工做幾年了，怎麼還犯一些新手級別的錯誤呢，這臉打得真是讓我至關慚愧。

5、總結

雖然是低級錯誤，但形成的後果也算挺嚴重了，此次事件也讓我更加的警醒，在之後的開發工做中必需要遵照該有的原則，大概有這麼幾點：

一、不能相信調用端

重要的參數都要先作驗證，即便是非空值也須要作驗證，不符合條件的就要直接返回或拋異常，不能參與業務sql的查詢，不然頻繁的訪問也會對服務形成負擔。

二、SQL語句要先作性能查詢

對於數據量大的表，建好索引後，全部的SQL查詢語句要用explain檢測性能，而且根據結果來進一步優化索引。

三、代碼必需要review

以前我沒有放太大的精力在代碼的review上，雖然說跟迭代排期的緊湊也有關係，但無論怎麼說，bug確實是個人疏忽形成的，尤爲是像空值這種細小的錯誤在Java裏能夠說屢見不鮮。

千里之堤毀於蟻穴，有時一個小bug很容易就引起整個系統的崩盤，這一次的問題也讓我更加深入的認識到了review代碼的重要性，無論業務開發的工做量有多麻煩，這一步操做絕對不能忽視。