一个 MySQL 隐式转换的坑，差点把服务器整崩溃了 _生活百科

我是风筝，公众号「古时的风筝」，专注于 Java技术及周边生态。文章会收录在 JavaNewBee 中，更有 Java 后端知识图谱，从小白到大牛要走的路都在里面。

本来是一个平静而美好的下午，其他部门的同事要一份数据报表临时汇报使用，因为系统目前没有这个维度的功能，所以需要写个SQL马上出一下，一个同事接到这个任务，于是开始在测试环境拼装这条 SQL，刚过了几分钟，同事已经自信的写好了这条SQL，于是拿给DBA，到线上跑一下，用客户端工具导出Excel 就好了，毕竟是临时方案嘛。
就在SQL执行了之后，意外发生了，先是等了一下，发现还没执行成功，猜测可能是数据量大的原因，但是随着时间滴滴答答流逝，逐渐意识到情况不对了，一看监控，CPU已经上去了，但是线上数据量虽然不小，也不至于跑成这样吧，眼看着要跑死了，赶紧把这个事务结束掉了。
什么原因呢？查询的条件和 join 连接的字段基本都有索引，按道理不应该这样啊，于是赶紧把SQL拿下来，也没看出什么问题，于是限制查询条数再跑了一次，很快出结果了，但是结果却大跌眼镜，出来的查询结果并不是预期的。

文章插图
经过一番检查之后，最终发现了问题所在，是 join 连接中有一个字段写错了，因为这两个字段有一部分名称是相同的，于是智能的 SQL 客户端给出了提示，顺手就给敲上去了。但是接下来，更让人迷惑了，因为要连接的字段是 int 类型，而写错的这个字段是 varchar 类型，难道不应该报错吗？怎么还能正常执行，并且还有预期外的查询结果？
难道是 MySQL 有 bug 了，必须要研究一下了。
复现当时的情景假设有两张表，这两张表的结构和数据是下面这样的。
第一张 user表。

CREATE TABLE `user` (`id` int(11) NOT NULL AUTO_INCREMENT,`name` varchar(50) COLLATE utf8_bin DEFAULT NULL,`age` int(3) DEFAULT NULL,`create_time` datetime DEFAULT NULL,`update_time` datetime DEFAULT NULL,PRIMARY KEY (`id`)) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8 COLLATE=utf8_bin;INSERT INTO `user` VALUES (1, '张三', 28, '2022-09-06 07:40:56', '2022-09-06 07:40:59');

文章插图
第二张 order表

CREATE TABLE `order` (`id` int(11) NOT NULL AUTO_INCREMENT,`user_id` int(11) DEFAULT NULL,`order_code` varchar(64) COLLATE utf8_bin DEFAULT NULL,`money` decimal(20,0) DEFAULT NULL,`title` varchar(255) COLLATE utf8_bin DEFAULT NULL,`create_time` datetime DEFAULT NULL,`update_time` datetime DEFAULT NULL,PRIMARY KEY (`id`)) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8 COLLATE=utf8_bin;INSERT INTO `order` VALUES (1, 2, '1d90530e-6ada-47c1-b2fa-adba4545aabd', 100, 'xxx购买两件商品', '2022-09-06 07:42:25', '2022-09-06 07:42:27');

文章插图
目的是查看所有用户的 order 记录，假设数据量比较少，可以直接查，不考虑性能问题。
本来的 SQL 语句应该是这样子的，查询 order表中用户iduser_id在user表的记录。
select o.* from `user` uleft JOIN `order` o on u.id = o.user_id;但是呢，因为手抖，将 on 后面的条件写成了 u.id = o.order_code，完全关联错误，这两个字段完全没有联系，而且u.id是 int 类型，o.order_code是varchar类型。
select o.* from `user` uleft JOIN `order` o on u.id = o.order_code;这样的话，当我们执行这条语句的时候，会不会查出数据来呢？
我的第一感觉是，不仅不会查出数据，而且还会报错，因为连接的这两个字段类型都不一样，值更不一样。
结果却被啪啪打脸，不仅没有报错，而且还查出了数据。

文章插图
可以把这个问题简化一下，简化成下面这条语句，同样也会出现问题。
select * from `order` where order_code = 1;

文章插图
明明这条记录的 order_code 字段的值是 1d90530e-6ada-47c1-b2fa-adba4545aabd，怎么用 order_code=1的条件就把它给查出来了。
根源所在相信有的同学已经猜出来了，这里是 MySQL 进行了隐式转换，由于查询条件后面跟的查询值是整型的，所以 MySQL 将