mysql 隐式转换问题

mysql 隐式转换问题

mysql隐式转换问题，特别在我们进行sql编写，sql优化的时候应该特别注意，可是大部分人都只知道mysql隐式转换，具体描述的时候却是有点模糊！

我们看上图，yhtest 表，第三列为c、varchar 类型，表中4行数据，当我们使用select * from yhtest where c=0; 进行查询的时候，有三个warning！

今天我们就从这三个warning 说起，后面的大部分内容可以解释为啥会有这三个warnings！

转换原则：当我们在使用where条件查询的时候，字段类型和赋值类型不一致时，都将转换成整型！ 这样一个描述其实是比较模糊的，下面我们具体来看。上图中字段类型为varchar 字符串类型，但是查询条件为c=0 整形，需要将字段内容都转换为整型，转换方式为：

1）纯字符串内容，则直接转换为0 ‘abc’ 将直接被转换为0

2）含有以数字开头的字符串 ，则会进行截取处理，截取至不是数字的字符串为止，比如‘4abc’ 将 转换为4 ，‘04abc’ 被转换为‘04’ 但是这个在匹配c=4的时候，是会被匹配到的

3）如果是纯数字字符串，那么将直接转换为对应的整形，比如‘4’ 将直接转换为4

4）以字符开头，数字结尾的，还是将转换为0

这样我们再看开头所报出的warnings ，顿时觉得合理了

很多sql优化的文章中强调：字符串一定记得在where条件中加引号，原因也正是在这里，下面我们看例子

执行 selectfrom yhtest where c=4 的结果和执行计划如下：

执行select 

from yhtest where c='4' 结果和执行计划如下：

通过执行计划我们看到，第一种where条件后面字段类型 和赋值类型不一致，隐式转换，也没有用到c列上的索引。第二种不存在隐式转换，使用了c列的索引，二者的查询结果也不一样！

上述隐式转换，大部分时候，我们需要用来避免隐式转换带来的不走索引，全表扫描，带来的sql性能问题，但是在数据少的时候，我们可以用来做一些特别操作，比如让'abcdefg'=0？