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

最新推荐文章于 2024-10-02 06:14:43 发布

小二上酒8

最新推荐文章于 2024-10-02 06:14:43 发布

阅读量300

点赞数

文章标签： mysql 服务器数据库 java 微服务

本文链接：https://blog.csdn.net/Huangjiazhen711/article/details/127700395

版权

本文讲述了作者在执行SQL查询时，由于字段类型错误导致的隐式转换问题，使得数据库性能急剧下降。通过复现情景和分析MySQL隐式转换规则，揭示了如何避免这类问题，强调了避免隐式转换的重要性，以防止对数据库造成严重的影响。

摘要由CSDN通过智能技术生成

本来是一个平静而美好的下午，其他部门的同事要一份数据报表临时汇报使用，因为系统目前没有这个维度的功能，所以需要写个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_INCRE