Mysql 一条update语句引发的血案

在长时间享受php的弱类型给我们开发带来的方便的同时，许多类型的定义已经在许多phper的身上渐走渐远了。 在这里总结一下前不久遇到的一个用php进行mysql访问时遇到的类型的问题，在mysql中对字段的定义都有着严定义的，当使用不同定义的过滤条件进行delete

在长时间享受php的弱类型给我们开发带来的方便的同时，许多类型的定义已经在许多phper的身上渐走渐远了。

在这里总结一下前不久遇到的一个用php进行mysql访问时遇到的类型的问题，在mysql中对字段的定义都有着严格定义的，当使用不同定义的过滤条件进行delete和update操作又会带来什么结果，下面将是一个实验。

建立测试环境：

创建测试表t2:create table t2(location varchar(10) , name varchar(50));

t2包含两个字段 location,name均为varchar型，插入数据：

insert into t2 values('askdfby', 'test01'),('1sdsdgrd', 'test02'), ('2sdlpdfgw', 'test03'), ('sdfnvashdfwsa', 'test04'),('sd2df84sdf', 'test04'),('123534sdsd', 'test05');

现在对location字段进行过滤查询：

mysql> select * from t2 where location = '0';

很显然结果为空集。但是当location的过滤条件不是char型而是int型呢，

mysql> select * from t2 where location = 0;
+------------+--------+
| location | name |
+------------+--------+
| askdfby | test01 |
| sdfnvashdf | test04 |
| sd2df84sdf | test04 |
+------------+--------+
3 rows in set (0.00 sec)

很奇怪竟然查出三条结果，再试试其他的：

mysql> select * from t2 where location = 1;
+----------+--------+
| location | name |
+----------+--------+
| 1sdsdgrd | test02 |
+----------+--------+
1 row in set (0.00 sec)

原来mysql在where子句中如果‘=’两边的类型不同的话，会将左端的转换成和右端相同的类型在进行比较（难道不应该是右端强转换成左端的类型么Orz）。

可以想象在线上环境中出现这样一条update的语句和delete的语句是怎样的灾难了（还好有备份，及时恢复了，接下来就是给人解释问题了，桑不起啊，桑不起。。）

所以说 各位程序员的看官们，写程序的时候真的要小心小心再小心，说不定那天很普通的一句sql就会掉到自己挖的坑里。