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

order_code字段进行了字符串到整数类型的转换，而转换后的结果正好是 1 。
通过 cast函数转换验证一下结果。
select cast('1d90530e-6ada-47c1-b2fa-adba4545aabd' as unsigned);【一个 MySQL 隐式转换的坑，差点把服务器整崩溃了】

文章插图
再用两条 SQL 看一下字符串到整数类型转换的规则。
select cast('223kkk' as unsigned);select cast('k223kkk' as unsigned);

文章插图
223kkk转换后的结果是 223，而k223kkk转换后的结果是0 。总结一下，转换的规则是：
1、从字符串的左侧开始向右转换，遇到非数字就停止；
2、如果第一个就是非数字，最后的结果就是0；
隐式转换的规则当操作符与不同类型的操作数一起使用的时候，就会发生隐式转换。
例如算数运算符的前后是不同类型时，会将非数字类型转换为数字，比如 '5a'+2，就会将5a转换为数字类型，然后和2相加，最后的结果就是 7。

文章插图
再比如 concat函数是连接两个字符串的，当此函数的参数出现非字符串类型时，就会将其转换为字符串，例如concat(88,'就是发')，最后的结果就是 88就是发 。

文章插图
MySQL 官方文档有以下几条关于隐式转换的规则：
1、两个参数至少有一个是 NULL 时，比较的结果也是 NULL，例外是使用 <=> 对两个 NULL 做比较时会返回 1，这两种情况都不需要做类型转换；
也就是两个参数中如果只有一个是NULL，则不管怎么比较结果都是 NULL，而两个 NULL 的值不管是判断大于、小于或等于，其结果都是1 。
2、两个参数都是字符串，会按照字符串来比较，不做类型转换；
3、两个参数都是整数，按照整数来比较，不做类型转换；
4、十六进制的值和非数字做比较时，会被当做二进制字符串；
例如下面这条语句，查询 user 表中name字段是 0x61 的记录，0x是16进制写法，其对应的字符串是英文的 'a'，也就是它对应的 ASCII 码。
select * from user where name = 0x61;所以，上面这条语句其实等同于下面这条
select * from user where name = 'a';可以用 select 0x61;验证一下。
5、有一个参数是 TIMESTAMP 或 DATETIME，并且另外一个参数是常量，常量会被转换为时间戳；
例如下面这两条SQL，都是将条件后面的值转换为时间戳再比较了，只不过

文章插图
6、有一个参数是 decimal 类型，如果另外一个参数是 decimal 或者整数，会将整数转换为 decimal 后进行比较，如果另外一个参数是浮点数（一般默认是 double），则会把 decimal 转换为浮点数进行比较；
在不同的数值类型之间，总是会向精度要求更高的那一个类型转换，但是有一点要注意，在MySQL 中浮点数的精度只有53 bit ，超过53bit之后的话，如果后面1位是1就进位，如果是0就直接舍弃。所以超大浮点数在比较的时候其实只是取的近似值。
7、所有其他情况下，两个参数都会被转换为浮点数再进行比较；
如果不符合上面6点规则，则统一转成浮点数再进行运算
避免进行隐式转换我们在平时的开发过程中，尽量要避免隐式转换，因为一旦发生隐式转换除了会降低性能外，还有很大可能会出现不期望的结果，就像我最开始遇到的那个问题一样。
之所以性能会降低，还有一个原因就是让本来有的索引失效。
select * from `order` where order_code = 1;order_code 是 varchar 类型，假设我已经在 order_code 上建立了索引，如果是用“=”做查询条件的话，应该直接命中索引才对，查询速度会很快。但是，当查询条件后面的值类型不是 varchar，而是数值类型的话， MySQL 首先要对 order_code 字段做类型转换，转换为数值类型，这时候，之前建的索引也就不会命中，只能走全表扫描，查询性能指数级下降，搞不好，数据库直接查崩了。
这位英俊潇洒的少年，如果觉得还不错的话，给个推荐可好！