1. 首頁 > 生活百科 > >

一個 MySQL 隱式轉換的坑，差點把服務器整崩潰了

生活百科

我是風箏，公眾號「古時的風箏」，專注于 Java技術 及周邊生態 。文章會收錄在 JavaNewBee 中，更有 Java 后端知識圖譜，從小白到大牛要走的路都在里面 。
本來是一個平靜而美好的下午，其他部門的同事要一份數據報表臨時匯報使用，因為系統目前沒有這個維度的功能，所以需要寫個SQL馬上出一下，一個同事接到這個任務，于是開始在測試環境拼裝這條 SQL，剛過了幾分鐘，同事已經自信的寫好了這條SQL，于是拿給DBA，到線上跑一下，用客戶端工具導出Excel 就好了，畢竟是臨時方案嘛 。
就在SQL執行了之后，意外發生了，先是等了一下，發現還沒執行成功，猜測可能是數據量大的原因 ， 但是隨著時間滴滴答答流逝，逐漸意識到情況不對了，一看監控，CPU已經上去了 ， 但是線上數據量雖然不小 ， 也不至于跑成這樣吧 ， 眼看著要跑死了，趕緊把這個事務結束掉了 。
什么原因呢？查詢的條件和 join 連接的字段基本都有索引，按道理不應該這樣啊，于是趕緊把SQL拿下來，也沒看出什么問題，于是限制查詢條數再跑了一次，很快出結果了，但是結果卻大跌眼鏡 ， 出來的查詢結果并不是預期的 。
一個 MySQL 隱式轉換的坑，差點把服務器整崩潰了

文章插圖
經過一番檢查之后，最終發現了問題所在，是 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');
一個 MySQL 隱式轉換的坑，差點把服務器整崩潰了

文章插圖
第二張 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');
一個 MySQL 隱式轉換的坑，差點把服務器整崩潰了

文章插圖
目的是查看所有用戶的 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;這樣的話 ，  當我們執行這條語句的時候，會不會查出數據來呢？
我的第一感覺是，不僅不會查出數據，而且還會報錯，因為連接的這兩個字段類型都不一樣，值更不一樣 。
結果卻被啪啪打臉，不僅沒有報錯，而且還查出了數據 。
一個 MySQL 隱式轉換的坑，差點把服務器整崩潰了

文章插圖
可以把這個問題簡化一下 ， 簡化成下面這條語句，同樣也會出現問題 。
select * from `order` where order_code = 1;
一個 MySQL 隱式轉換的坑，差點把服務器整崩潰了

文章插圖
明明這條記錄的 order_code 字段的值是 1d90530e-6ada-47c1-b2fa-adba4545aabd，怎么用 order_code=1的條件就把它給查出來了 。
根源所在相信有的同學已經猜出來了，這里是 MySQL 進行了隱式轉換 ， 由于查詢條件后面跟的查詢值是整型的，所以 MySQL 將

推薦閱讀