一、生產出錯！
今天早上11點左右，我在工作休息之餘，擼了一下貓。突然，工作羣響了，老大在裏面說：APP出錯了！
媽啊，這太嚇人了，因爲只是說了出錯，但是沒說錯誤的信息。所以我趕緊到APP上看看。
這果然是出錯了，而且還是簡單而粗暴的500，太嚇人了。
二、本地趕緊調試起來！
既然線上出錯了，我們又不能直接進行調試，那當然得馬上在本地搞起來了！
1、代碼是否有錯？
立馬拉取最新的代碼（怕有同事更新過），然後啓動本地的項目，訪問對應的接口，看看是不是代碼哪裏出錯了。
好了，本地的代碼和 SQL 都是沒錯的！
2、是否測試庫和生產庫有更新？
那麼是不是測試庫和生產庫的表改了啥？
我又立馬拿着後臺打印的 SQL 直接去到測試庫上面執行一遍，看看究竟是不是 SQL 可能存在問
題。emm，結果還是沒錯。
至於生產庫，因爲是在家辦公，測不了~而且，一般修改都是先本地，接着測試，最後再生產吧。但是也有可能是緊急的需求，直接上生產了，這個也不好說。
此時，首先我們可以得出兩個點。
- 代碼是沒問題的，因爲本地的項目訪問正常。
- 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、總結：
- 所以說。雖然寫 SQL 很簡單，但是我們一定要按照規範些，不能說現在不出錯就是沒問題了，按照規範寫更是爲了避免以後的出錯，以後我也要好好注意才行！
- 而且，我們既然做了全局異常處理，但是一定要將錯誤信息打印到後臺或者是日誌中，不然就像今次找不到具體的錯誤信息了~
題外話：
當然了，寫出一手好 SQL ，不但要按照規範寫，還需要深刻理解 MySQL 的組件和機制的原理。例如：binlog、undo、innoDB存儲引擎、鎖、索引和事務等等。
如果大家也想深入學習 MySQL ，可以關注我現在不斷在輸出的【大白話系列】MySQL 學習總結專欄。