上週四午休時分，我正在工位上小憩，睡夢中彷彿看到了本身拿着李白在榮耀峽谷裏大殺四方的情景，就在我剛拿完五殺準備帶領隊友推對面水晶的時候，一句慌亂急促的「糟了」把我從睡夢中驚醒......java
反常的 SQL 語句程序員
我眯開朦朧的雙眼，才發現剛纔的發聲來源於個人組長莊哥，看到他在緊張的點開日誌系統查看日誌，我預感到有什麼不妙的事情發生。數據庫
仔細一問才知道，原來就在我眯眼的期間，線上數據庫服務器的 CPU 被打滿，同時觸發了生產數據庫只讀延遲的限定時間而且發出告警，並且告警的過程持續了半個小時。服務器
這讓我倒吸了一口涼氣，由於咱們組作的系統不少都用的是同一個數據庫服務器，日用戶活躍量有好幾十萬，若是服務器崩潰了將會使全部的系統服務都不可用。性能
因而咱們趕忙經過 SQL 日誌進行問題查找，最後排查出來是由於一張 SQL 的高量查詢沒有走索引致使。優化
日誌列表顯示，這條 SQL 語句的掃描行數達到了上百萬，基本就是全表掃描的狀況，並且半個小時的時間查詢了達上萬次，每條 SQL 查詢的耗時都在 3000ms 以上。ui
個人天啊，難怪服務器會 CPU 打滿，這麼一條耗時的 SQL 語句查詢量這麼大，數據庫的資源固然是直接就崩潰了。設計
這是當時那條 SQL 的查詢狀況： 
臨時處理日誌
看了這條語句，我又倒吸一口涼氣，這不就是我寫的系統調用的 SQL 語句嗎？完了，這回逃不掉了，真是人在睡夢裏，鍋從天上來。 固然，由於是我本身寫的 SQL，因此我一看就知道這條語句是有問題的。code
根據個人代碼處理，這條 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 的掃描行數就大幅度的下降了，重啓實例後就又能正常運行了。
最左匹配原則
那麼爲何最左側的字段沒傳索引就不生效了，這是由於 MySQL 的聯合索引是基於「最左匹配原則」匹配的。
咱們都知道，索引的底層是 B+ 樹結構，聯合索引的結構也是 B+ 樹，只不過鍵值數量不是一個，而是多個，構建一顆 B+ 樹只能根據一個值來構建，所以數據庫依據聯合索引最左的字段來構建 B+ 樹。
例如咱們用兩個字段（name，age）這個聯合索引來分析： 圖片來源於林曉斌老師的《MySQL 實戰 45 講》課程
當咱們在 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) 這兩個索引。
找出 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 查詢，而且在不跑索引的狀況下直接走全表掃描。 不得不說，這真是個低級錯誤，說真的，我對這個緣由真是感到嘀笑皆非，再怎麼說也工做幾年了，怎麼還犯一些新手級別的錯誤呢，這臉打得真是讓我至關慚愧。
總結
雖然是低級錯誤，但形成的後果也算挺嚴重了，此次事件也讓我更加的警醒，在之後的開發工做中必需要遵照該有的原則，大概有這麼幾點：
①不能相信調用端。重要的參數都要先作驗證，即便是非空值也須要作驗證，不符合條件的就要直接返回或拋異常，不能參與業務 SQL 的查詢，不然頻繁的訪問也會對服務形成負擔。
②SQL 語句要先作性能查詢。對於數據量大的表，建好索引後，全部的 SQL 查詢語句要用 explain 檢測性能，而且根據結果來進一步優化索引。
③代碼必需要 Review。以前我沒有放太大的精力在代碼的 Review 上，雖然說跟迭代排期的緊湊也有關係，但無論怎麼說，Bug 確實是個人疏忽形成的，尤爲是像空值這種細小的錯誤在 Java 裏能夠說屢見不鮮。
千里之堤毀於蟻穴，有時一個小 Bug 很容易就引起整個系統的崩盤，這一次的問題也讓我更加深入的認識到了 Review 代碼的重要性，無論業務開發的工做量有多麻煩，這一步操做絕對不能忽視。
來自：鄙人薛某 做者：很懶的程序員