MySQL中`select `*` from table`在特定版本下竟不报错？本文带你探寻这一怪异现象背后的原因，并get快速排查问题的方法。
原文标题：select `*` from table 语法居然不报错？
原文作者：阿里云开发者
冷月清谈：
怜星夜思：
2、文章中使用了二分法来定位问题版本，你觉得在排查数据库问题时，还有哪些高效的排查方法？
3、文章提到了`dbdeployer`工具可以快速构建不同版本的数据库，你有没有使用过类似的工具？或者你有什么其他推荐的快速搭建数据库环境的方法？
原文内容
阿里妹导读
一、前言
在MySQL中，反引号 ` 实际上是用来引用数据库对象的名称，如表名、列名等，以区分MySQL的保留关键字和特殊字符。而星号 * 用作通配符，它不需要用反引号引用。下面语句的反引号 ` 通常用于引用标识符，不适用于表中所有列输出，在标准的MySQL中，这实际上会产生一个错误，因为没有列名为 * 的列。
select `*` from table;
但是在客户的数据库中，该SQL却执行成功了，但是我在另外一台测试数据库中，却是报错，理论上报错是符合预期的，那客户的数据库是怎么回事呢？
这里不建议大家关注业务影响，这个问题可大可小，主要是兴趣所致分析该问题的原因：
-
如果只是客户业务不经常调用，且业务代码可以随意调整，让客户优化掉这个问题反引号的问题，正确使用即可；
-
可如果客户业务代码写死，客户将同样的数据已经迁移到另外一套数据库中，业务频繁使用 select `*` ，频繁报错，那么这个问题就很严重了，生产业务中就是一堆报错。
二、测试验证
本着深入探究问题的动机，作为小白，我们应该做大量单变量测试，不断向问题原因靠拢，最终定位。
-
经过一系列的排查测试，对齐相关因素后，当前问题与sql_mode、库表字符集均无关。
-
ANSI_QUOTES 限制的是双引号的使用，与反引号的使用无关。
-
在网上 Google 也不容易搜到类似的问题和报错信息，问题一度陷入困境。
本地尝试相同版本的数据库，发现问题复现了。但是在高版本的数据库中就没有出现，从而推断，这个问题在高版本数据库已经解决了。然后我们使用二分法，从低/高版本分别测试，验证问题复现版本，寻找交叉点，来判断下这个问题的解决版本。
create table t1(id int,name varchar(255));insert into t1 value(1,'chenyuan'),(2,'liu');mysql [localhost:5712] {root} (test) > select
*from t1;
±-----±---------+
| id | name |
±-----±---------+
| 1 | chenyuan |
| 2 | liu |
±-----±---------+
2 rows in set (0.00 sec)mysql [localhost:5720] {root} (test) > select
*from t1;
±-----±---------+
| id | name |
±-----±---------+
| 1 | chenyuan |
| 2 | liu |
±-----±---------+
2 rows in set (0.00 sec)mysql [localhost:5725] {root} (test) > select
*from t1;
±-----±---------+
| id | name |
±-----±---------+
| 1 | chenyuan |
| 2 | liu |
±-----±---------+
2 rows in set (0.00 sec)mysql [localhost:5729] {root} (test) > select
*from t1;
±-----±---------+
| id | name |
±-----±---------+
| 1 | chenyuan |
| 2 | liu |
±-----±---------+
2 rows in set (0.00 sec)mysql [localhost:5730] {root} (test) > select
*from t1;
±-----±---------+
| id | name |
±-----±---------+
| 1 | chenyuan |
| 2 | liu |
±-----±---------+
2 rows in set (0.00 sec)mysql [localhost:5731] {root} (test) > select
*from t1;
ERROR 1054 (42S22): Unknown column ‘*’ in ‘field list’mysql [localhost:5732] {root} (test) > select
*from t1;
ERROR 1054 (42S22): Unknown column ‘*’ in ‘field list’mysql [localhost:5733] {root} (test) > select
*from t1;
ERROR 1054 (42S22): Unknown column ‘*’ in ‘field list’
mysql [localhost:5741] {root} (test) > select*from t1;
ERROR 1054 (42S22): Unknown column ‘*’ in ‘field list’
三、结论
从上面的测试可以得出，当前这个缺陷，MySQL官方应该在5.7.31的发布中修复了，那么究竟触发了什么bug呢？
MySQL 5.7.31 Release Notes：https://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-31.html
我们可以看下5731做了哪些变更。当前这个问题还是很有区分度的，直接就扫到了原因和Bug号。
It is possible to define a column named * (single asterisk character), but SELECT `*` was treated identically to SELECT *, making it impossible to select only this column in a query; in other words, the asterisk character was expanded to a list of all table columns even when it was surrounded by backticks. (Bug #30528450)
-
进一步在Github上找到对应的patch：
-
5.7的patch【修复版本5731】：https://github.com/mysql/mysql-server/commit/5c8c085ba96d30d697d0baa54d67b102c232116b
-
8.0的patch【修复版本8021】：https://github.com/mysql/mysql-server/commit/bdc8816873ff891b17d1ed6c5266f0ecfc2fa1f5
就当前的问题而言，我们命中了5.7 patch中的Issue 1。
简单总结：在MySQL的 WL#7200WorkLog中，官方对select语句的解析进行了重构，导致对 `*` 的处理发生了异常，无效的*会被Item_field::itemize()类处理，而该方法没有处理 `*` 的逻辑，致使反引号没有被正确应用。
5731之后的优化：删除 Item_field::itemize() 类中检查 select结构体中 field_name 为 * 的处理方法，新增一个类Item_asterisk用于处理SQL查询中的通配符 *。它在构造时记录通配符的使用，并在itemize成员函数中进行进一步的处理。
四、写在最后
这篇文章并不是对标数据库的研发同学，而是针对大多数不懂C++代码的售后/DBA同学，说的是一种问题分析方法，我们遇到类似的bug行为应该如何判断？二分法判断问题的关键节点，从而能更进一步的确认到问题原因。
特别感谢前老板三年的栽培，让我从数据库慢慢入门，无数加班的夜晚，讨论并指导了我很多技术问题，慢慢淬炼，以后的路再接再厉。
彩蛋：快速构建不同版本数据库，大家可以考虑使用 dbdeployer 工具。