一、生產出錯！

今天早上11點左右，我在工作休息之餘，擼了一下貓。突然，工作群響了，老大在裡面說：APP出錯了！

媽啊，這太嚇人了，因為只是說了出錯，但是沒說錯誤的資訊。所以我趕緊到APP上看看。

這果然是出錯了，而且還是簡單而粗暴的500，太嚇人了。

二、本地趕緊除錯起來！

既然線上出錯了，我們又不能直接進行除錯，那當然得馬上在本地搞起來了！

1、程式碼是否有錯？

立馬啟動本地的專案，訪問對應的介面，看看是不是程式碼哪裡出錯了。

好了，本地的程式碼和 SQL 都是沒錯的！

2、SQL 是否有錯？

那麼是不是測試庫和生產庫的表改了啥？

我又立馬拿著後臺列印的 SQL 直接去到測試庫上面執行一遍，看看究竟是不是 SQL 可能存在問

至於生產庫，因為是在家辦公，測不了~而且，一般修改都是先本地，接著測試，最後再生產吧。但是也有可能是緊急的需求，直接上生產了，這個也不好說。

此時，首先我們可以得出兩個點。

1. 程式碼是沒問題的，因為本地的專案訪問正常。

2. SQL 暫時也是沒問題的，因為在本地庫和測試庫執行都沒問題。

   3、猜想~

   所以說，出現這個 bug，很有可能是有人直接對生產庫的某個表進行了修改，而且我介面的 SQL 還用到了！

三、我啥都沒改就又可以了！

1、找到原因了

既然程式碼和 SQL 都測過沒問題了，只剩下生產庫待確認了。

果不其然，不一會兒，老大又在群裡說介面沒問題了。老大的回覆很明顯，就是生產環境的某個表增加了一個欄位，而且我的 SQL 確實用到那個表了。

2、深入原因

再回頭來看看介面的 SQL，根據 tag 這個關鍵字搜尋一下哪裡用到了。發現了只有一個函式是關於 tag 的，所以去資料庫裡面看看這個函式。

函式原始碼：

到了這裡，相信大家都曉得是什麼情況了。

一個表新增 tag 欄位後，導致兩個表同時存在命名為 tag 的欄位。而查詢的時候沒加上對應的表字首，導致 MySQL 無法識別結果集到底是用哪個表的 tag 欄位，最後就報錯了。

四、具體的錯誤資訊和總結

1、獲取具體的錯誤資訊

原來僅僅是一個小小的 SQL 規範問題，導致了一次生產線上的 bug。

因為異常是經過封裝的，所以 APP 只返回了伺服器異常（500）。所以我在本地重現了一下這個 bug，就是為了拿到具體的錯誤資訊。

錯誤資訊很簡單和明瞭：Column 'tag' in field list is ambiguous。中文就是欄位 tag 模稜兩可。

2、總結：

1. 所以說。雖然寫 SQL 很簡單，但是我們一定要按照規範些，不能說現在不出錯就是沒問題了，按照規範寫更是為了避免以後的出錯，以後我也要好好注意才行！
2. 而且，我們既然做了全域性異常處理，但是一定要將錯誤資訊列印到後臺或者是日誌中，不然就像今次找不到具體的錯誤資訊了~

題外話：

當然了，寫出一手好 SQL ，不但要按照規範寫，還需要深刻理解 MySQL 的元件和機制的原理。例如：binlog、undo、innoDB儲存引擎、鎖、索引和事務等等。

如果大家也想深入學習 MySQL ，可以關注我現在不斷在輸出的【大白話系列】MySQL 學習總結專欄