【MySQL 線上 BUG 分析】之 多表同字段異常：Column ‘xxx’ in field list is ambiguous

1、生產出錯！

今天早上11點左右，我在工做休息之餘，擼了一下貓。忽然，工做羣響了，老大在裏面說：APP出錯了！ 媽啊，這太嚇人了，由於只是說了出錯，可是沒說錯誤的信息。因此我趕忙到APP上看看。 這果真是出錯了，並且仍是簡單而粗暴的500，太嚇人了。

2、本地趕忙調試起來！

既然線上出錯了，咱們又不能直接進行調試，那固然得立刻在本地搞起來了！

一、代碼是否有錯？

立馬啓動本地的項目，訪問對應的接口，看看是否是代碼哪裏出錯了。 好了，本地的代碼和 SQL 都是沒錯的！

二、SQL 是否有錯？

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

我又立馬拿着後臺打印的 SQL 直接去到測試庫上面執行一遍，看看到底是不是 SQL 可能存在問 題。emm，結果仍是沒錯。

至於生產庫，由於是在家辦公，測不了~並且，通常修改都是先本地，接着測試，最後再生產吧。可是也有多是緊急的需求，直接上生產了，這個也很差說。

此時，首先咱們能夠得出兩個點。

1. 代碼是沒問題的，由於本地的項目訪問正常。
2. SQL 暫時也是沒問題的，由於在本地庫和測試庫執行都沒問題。

三、猜測~

因此說，出現這個 bug，頗有多是有人直接對生產庫的某個表進行了修改，並且我接口的 SQL 還用到了！

3、我啥都沒改就又能夠了！

一、找到緣由了

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

果不其然，不一下子，老大又在羣裏說接口沒問題了。老大的回覆很明顯，就是生產環境的某個表增長了一個字段，並且個人 SQL 確實用到那個表了。

二、深刻緣由

再回頭來看看接口的 SQL，根據 tag 這個關鍵字搜索一下哪裏用到了。發現了只有一個函數是關於 tag 的，因此去數據庫裏面看看這個函數。 函數源碼： 到了這裏，相信你們都曉得是什麼狀況了。

一個表新增 tag 字段後，致使兩個表同時存在命名爲 tag 的字段。而查詢的時候沒加上對應的表前綴，致使 MySQL 沒法識別結果集究竟是用哪一個表的 tag 字段，最後就報錯了。

4、具體的錯誤信息和總結

一、獲取具體的錯誤信息

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

由於異常是通過封裝的，因此 APP 只返回了服務器異常（500）。因此我在本地重現了一下這個 bug，就是爲了拿到具體的錯誤信息。

錯誤信息很簡單和明瞭：Column 'tag' in field list is ambiguous。中文就是字段 tag 模棱兩可。

二、總結：

1. 因此說。雖然寫 SQL 很簡單，可是咱們必定要按照規範些，不能說如今不出錯就是沒問題了，按照規範寫更是爲了不之後的出錯，之後我也要好好注意才行！
2. 並且，咱們既然作了全局異常處理，可是必定要將錯誤信息打印到後臺或者是日誌中，否則就像今次找不到具體的錯誤信息了~

題外話：

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

若是你們也想深刻學習 MySQL ，能夠關注我如今不斷在輸出的【大白話系列】MySQL 學習總結專欄。

原文出處：https://www.cnblogs.com/Howinfun/p/12341593.html