Mysql数据类型错误引起的问题

摘要: Mysql数据类型错误导致查询超时，更新出错等问题

前段时间发现后台某个查询经常超时，后来通过排查，把SQL语句打印出来，结果发现：



原来是开发人员在查询日期时，在参数里不小心增加了一个单引号，好了，到此问题出现了，原来是粗心大意的错误。但是，当我再深究下去，既然字段类型是日期，但参数是字符串，为何mysql没有报错呢？

后来我将语句复制到Mysql的查询器里测试，发现这个SQL语句可以正常查出结果(改为其它日期可以查出相应的结果)，mysql并没有报错，但是查询时间十分长，平均需要40多秒，这就是后台报time-out的原因吧。

由于这个表数据量，我们之前做了索引，因此我猜这个语句是没有使用索引的。然后我把错误的单引号去掉重新查，发现结果几乎是秒出，然后我猜想，是那个单引号导致参数类型变为字符串，不符合索引字段类型，从而没有使用索引。

于是在查询器使用“explain”分析语句，结果显示虽然使用了索引，但是检索范围并没有得到有效的减少，几乎是全表检索；而正确的语句通过索引缩小到只有9W多行，因此结果都是秒出的了。







做成这个问题的根本原因是mySql5.5和5.1版本在类型转换时有问题。

下面看一个实例：

假设我需要修改name = 23的名字，在查询器里输入SQL语句：SELECT * FROM test_1 WHERE NAME = 23 ，然后得出的结果是：



如果此时更新语句：UPDATE test_1 SET NAME = 24 WHERE NAME = 23;，我可以很负责任地说会进行全表更新。

做出这个原因是，当所使用的条件的字段值类型和数据库的定义的字段类型不一样时，MySQL就会在内部做数据转化，将数据库中的记录转化为整数做比较，将空值转化为整数0做比较。在字符串转化过程中，遇到特殊符号是会舍去特殊符号和后面的值，所以就会出现上述情况了。

这个问题告诫我们，在where 的条件中，字段类型与给定值类型必须对应。对应是有好处的，能够促使条件走上索引，当然也不会踩上诸如上面的地雷，万一不小心，就把全表给更新了，PS：据说oracle 是相反操作的，即把条件类型转换为数据表类型，从而不会出现上述问题，为什么不转换条件中的一个字段类型，而转换表中过千万的字段类型，mysql这个做法的确令人无法理解。