一个 MySQL 隐式转换的坑,差点把服务器整崩溃了( 三 )


文章插图
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 字段做类型转换,转换为数值类型,这时候,之前建的索引也就不会命中,只能走全表扫描,查询性能指数级下降,搞不好,数据库直接查崩了 。
这位英俊潇洒的少年,如果觉得还不错的话,给个推荐可好!
公众号「古时的风筝」,Java 开发者,全栈工程师,bug 杀手,擅长解决问题 。一个兼具深度与广度的程序员鼓励师,本打算写诗却写起了代码的田园码农!坚持原创干货输出,你可选择现在就关注我,或者看看历史文章再关注也不迟 。长按二维码关注,跟我一起变优秀!

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

文章插图
【一个 MySQL 隐式转换的坑,差点把服务器整崩溃了】

经验总结扩展阅读