一、前言

在一個(gè)陽(yáng)光明媚的下午，我們的測(cè)試在運(yùn)行SQL時(shí)發(fā)現(xiàn)了一個(gè)靈異事件。別著急，等我慢慢說(shuō)來(lái)，是一個(gè)查詢(xún)庫(kù)存的SQL，控制臺(tái)打印了，查詢(xún)?yōu)?條記錄。想著不太信，自己把SQL粘出來(lái)執(zhí)行一下，「剛好有個(gè)varchar類(lèi)型的字段，查詢(xún)的是一堆數(shù)字，忘記加引號(hào)了?！菇Y(jié)果查詢(xún)出來(lái)了一條！

從頭看到結(jié)尾，發(fā)現(xiàn)我們查詢(xún)條件的字段值為231120103，把數(shù)據(jù)庫(kù)中231120103-1的查詢(xún)出來(lái)了！

經(jīng)過(guò)半天的探索，「發(fā)現(xiàn)這是MySQL優(yōu)化器中，判斷數(shù)據(jù)類(lèi)型不匹配的比較時(shí)，MySQL 優(yōu)化器會(huì)進(jìn)行隱式類(lèi)型轉(zhuǎn)換！」

下面我們一起來(lái)看看這個(gè)隱式轉(zhuǎn)換，到底是怎么轉(zhuǎn)換的！

要知其然，知其所以然。

二、實(shí)踐出真知

1、建表

CREATE TABLE `str_test`  (
  `id` int(0) NOT NULL,
  `str_column` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NULL DEFAULT NULL,
  `int_column` int(0) NULL DEFAULT NULL,
  PRIMARY KEY (`id`) USING BTREE
) ENGINE = InnoDB CHARACTER SET = utf8mb4 COLLATE = utf8mb4_general_ci ROW_FORMAT = Dynamic;

我們新建一個(gè)表，里面有varchar和int類(lèi)型，插入幾條方便測(cè)試！

INSERT INTO `test`.`str_test`(`id`, `str_column`, `int_column`) VALUES (1, '123', 123);
INSERT INTO `test`.`str_test`(`id`, `str_column`, `int_column`) VALUES (2, '123-1---1122', 12);
INSERT INTO `test`.`str_test`(`id`, `str_column`, `int_column`) VALUES (3, 'abc', 1);
INSERT INTO `test`.`str_test`(`id`, `str_column`, `int_column`) VALUES (4, '783221667772672728', 2147483647);
INSERT INTO `test`.`str_test`(`id`, `str_column`, `int_column`) VALUES (5, '783221667772672798', 2147483647);
INSERT INTO `test`.`str_test`(`id`, `str_column`, `int_column`) VALUES (6, '0', 0);

2、測(cè)試查詢(xún)

我們先以int類(lèi)型查詢(xún)varchar作為測(cè)試：

SELECT * FROM `str_test` WHERE str_column = 123;

大家是不是認(rèn)為這里只能查詢(xún)出一條數(shù)據(jù)，答案是錯(cuò)誤的！我們后面統(tǒng)一說(shuō)結(jié)論，這里先看測(cè)試！

我們?cè)诓迦胍粭lstr_column位數(shù)超過(guò)18位的！讓轉(zhuǎn)化時(shí)丟失精度，從而實(shí)現(xiàn)多查的情況！

我們看到查詢(xún)的和被查詢(xún)出來(lái)的是不一樣的！

我們?cè)谝詖archar來(lái)查詢(xún)int字段：

SELECT * FROM `str_test` WHERE int_column = '12A333';

還是可以查詢(xún)到數(shù)據(jù)！

3、結(jié)論

經(jīng)過(guò)上面的測(cè)試是不是已經(jīng)汗流浹背了！不要慌，下面我們來(lái)揭曉答案！

有興趣的可以看看官網(wǎng)文檔：MySQL5.7文檔：https://dev.mysql.com/doc/refman/5.7/en/type-conversion.html

?

當(dāng)整數(shù)與字符串進(jìn)行比較時(shí)，無(wú)論數(shù)據(jù)庫(kù)是int還是varchar，只要類(lèi)型不一致時(shí)，MySQL會(huì)嘗試將字符串轉(zhuǎn)換為整數(shù)進(jìn)行比較。 

如果字符串以有效的數(shù)字開(kāi)頭，則將其轉(zhuǎn)換為相應(yīng)的整數(shù)值。 

解析規(guī)則：從開(kāi)頭解析直到遇到非數(shù)字的字符結(jié)束，前面的會(huì)作為比較的值，非數(shù)字后面的直接拋棄。 

如果字符串以非數(shù)字字符開(kāi)頭，將被轉(zhuǎn)化為0。 

數(shù)值過(guò)大時(shí)，回傳精度損失，也會(huì)出現(xiàn)匹配。沒(méi)找到具體的臨界值，超過(guò)18位會(huì)出現(xiàn)浮點(diǎn)數(shù)精度損失！

?

三、隱式轉(zhuǎn)換的缺點(diǎn)

• 精度損失：隱式轉(zhuǎn)換可能導(dǎo)致精度損失問(wèn)題，上面我們演示過(guò)了。
• 性能開(kāi)銷(xiāo)：在進(jìn)行大規(guī)模數(shù)據(jù)處理時(shí)，頻繁的隱式轉(zhuǎn)換可能會(huì)對(duì)性能產(chǎn)生影響。
• 索引失效：存在隱式轉(zhuǎn)換會(huì)讓優(yōu)化器無(wú)法使用索引進(jìn)行優(yōu)化查詢(xún)，影響響應(yīng)時(shí)間。
• 數(shù)據(jù)安全風(fēng)險(xiǎn)：如果是一個(gè)刪除語(yǔ)句，像上面演示的會(huì)出現(xiàn)匹配到其他行，從而導(dǎo)致數(shù)據(jù)被誤刪。還有多查的問(wèn)題。

四、總結(jié)

當(dāng)然這個(gè)其實(shí)也是一個(gè)面試題，大家是不是已經(jīng)會(huì)了！

之前在MySQL索引失效時(shí)，就了解過(guò)隱式轉(zhuǎn)換，只知道會(huì)轉(zhuǎn)換，今天才有了更深刻的認(rèn)識(shí)。

其實(shí)這個(gè)情況我們還是要避免的，不能是MySQL不給我們報(bào)錯(cuò)，我們就這樣不規(guī)范的寫(xiě)。

這要是生產(chǎn)上，一個(gè)刪除匹配到多條，和刪庫(kù)跑路性質(zhì)一樣了！

大家還是要小心哈，一定不要出現(xiàn)隱式轉(zhuǎn)換！