社区微信群开通啦，扫一扫抢先加入社区官方微信群
社区微信群
今天早上11点左右，我在工作休息之余，撸了一下猫。突然，工作群响了，老大在里面说：APP出错了！
妈啊，这太吓人了，因为只是说了出错，但是没说错误的信息。所以我赶紧到APP上看看。
这果然是出错了，而且还是简单而粗暴的500，太吓人了。
既然线上出错了，我们又不能直接进行调试，那当然得马上在本地搞起来了！
立马拉取最新的代码（怕有同事更新过），然后启动本地的项目，访问对应的接口，看看是不是代码哪里出错了。
好了，本地的代码和 SQL 都是没错的！
那么是不是测试库和生产库的表改了啥？
我又立马拿着后台打印的 SQL 直接去到测试库上面执行一遍，看看究竟是不是 SQL 可能存在问
题。emm，结果还是没错。
至于生产库，因为是在家办公，测不了~而且，一般修改都是先本地，接着测试，最后再生产吧。但是也有可能是紧急的需求，直接上生产了，这个也不好说。
此时，首先我们可以得出两个点。
所以说，出现这个 bug，很有可能是有同事直接对生产库的某个表进行了修改，而且我接口的 SQL 还用到了！
既然代码和 SQL 都测过没问题了，只剩下生产库待确认了。
果不其然，不一会儿，老大又在群里说接口没问题了。老大的回复很明显，就是生产环境的某个表增加了一个字段，而且我的 SQL 确实用到那个表了。
再回头来看看接口的 SQL，根据 tag 这个关键字搜索一下哪里用到了。发现了只有一个函数是关于 tag 的，所以去数据库里面看看这个函数。
函数源码：
到了这里，相信大家都晓得是什么情况了。
一个表新增 tag 字段后，导致两个表同时存在命名为 tag 的字段。而查询的时候没加上对应的表前缀，导致 MySQL 无法识别结果集到底是用哪个表的 tag 字段，最后就报错了。
原来仅仅是一个小小的 SQL 规范问题，导致了一次生产线上的 bug。
因为异常是经过封装的，所以 APP 只返回了服务器异常（500）。所以我在本地重现了一下这个 bug，就是为了拿到具体的错误信息。
错误信息很简单和明了：Column ‘tag’ in field list is ambiguous。中文就是字段 tag 模棱两可。
题外话：
当然了，写出一手好 SQL ，不但要按照规范写，还需要深刻理解 MySQL 的组件和机制的原理。例如：binlog、undo、innoDB存储引擎、锁、索引和事务等等。
如果大家也想深入学习 MySQL ，可以关注我现在不断在输出的【大白话系列】MySQL 学习总结专栏。
如果觉得我的文章对您有用，请随意打赏。你的支持将鼓励我继续创作！
