【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