一、生產出錯！
今天早上11點左右，我在工作休息之余，擼了一下貓。突然，工作群響了，老大在里面說：APP出錯了！
媽啊，這太嚇人了，因為只是說了出錯，但是沒說錯誤的信息。所以我趕緊到APP上看看。
這果然是出錯了，而且還是簡單而粗暴的500，太嚇人了。
二、本地趕緊調試起來！
既然線上出錯了，我們又不能直接進行調試，那當然得馬上在本地搞起來了！
1、代碼是否有錯？
立馬啟動本地的項目，訪問對應的接口，看看是不是代碼哪里出錯了。
好了，本地的代碼和 SQL 都是沒錯的！
2、SQL 是否有錯？
那么是不是測試庫和生產庫的表改了啥？
我又立馬拿着后台打印的 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 學習總結專欄。